DEV Community: Ashish Patel

Turborepo + Vite with React Monorepo (Part 2)

Ashish Patel — Tue, 17 Feb 2026 06:51:42 +0000

This is Part 2 of a two-part series. Part 1 covered the migration itself — moving 500+ files to a pnpm monorepo, fixing CSS resolution, and debugging a Firebase singleton bug that only appears under pnpm's strict module isolation.

This post covers what happens after migration: integrating feature branches that don't know the monorepo exists, adding a second app under a sub-path, and the git merge strategy that turned 45 conflicts into zero.

The Problem: Three Branches, One Migration

After the migration landed on chore/monorepo-migration, we had two feature branches still built against the old flat src/ structure:

feat/marketplace-integration — A new marketplace app with 14 commits, including its own (broken) monorepo migration attempt
feat/automated-outreach — A 110-file, 18-commit feature built entirely against src/

Both needed to land on the migrated branch. Both had files that overlapped with each other and with the base. This is where things got interesting.

Adding a Second App to the Monorepo

The marketplace was a separate React app that needed to live under a sub-path: example.com/marketplace. Same domain as the dashboard, different app.

The workspace setup

# pnpm-workspace.yaml
packages:
  - "apps/*"
  - "packages/*"

apps/
├── dashboard/     # localhost:3002
└── marketplace/   # localhost:3003, hosted at /marketplace

// apps/marketplace/package.json
{
  "name": "@acme/marketplace",
  "scripts": {
    "dev": "vite --port 3003"
  }
}

// Root package.json
{
  "scripts": {
    "dev": "turbo dev",
    "dev:dashboard": "pnpm --filter @acme/dashboard dev",
    "dev:marketplace": "pnpm --filter @acme/marketplace dev"
  }
}

turbo dev starts both apps in parallel. Simple enough. The complexity is in sub-path hosting.

The five layers of sub-path configuration

Sub-path hosting means the marketplace is served at /marketplace instead of /. This requires five things to agree, and missing any one produces a blank white screen with no error message.

Layer 1: Vite base

// apps/marketplace/vite.config.js
export default defineConfig({
  base: "/marketplace/",
  server: { port: 3003 },
});

This tells Vite to prefix all asset URLs with /marketplace/. Without it, the app tries to load main.js from / instead of /marketplace/main.js.

Layer 2: React Router basename

// apps/marketplace/src/index.jsx
<BrowserRouter basename="/marketplace">
  <App />
</BrowserRouter>

Without this, the router doesn't recognize /marketplace/some-page as a valid route. All navigation fails silently.

Layer 3: Dev proxy

// apps/dashboard/vite.config.js
server: {
    proxy: {
        "/marketplace": {
            target: "http://localhost:3003",
            changeOrigin: true,
        },
    },
}

During development, the dashboard runs on port 3002. When a request comes in for /marketplace/*, the proxy forwards it to the marketplace dev server on port 3003.

Layer 4: The trailing slash

This one cost us 2 hours.

The browser requests /marketplace (no trailing slash). The proxy matches and forwards to port 3003. But the marketplace's Vite server expects /marketplace/ (with trailing slash) because that's its base. The HTML never loads. Blank screen. No error.

The fix — a 12-line Vite plugin:

function marketplaceRedirect() {
  return {
    name: "marketplace-redirect",
    configureServer(server) {
      server.middlewares.use((req, _res, next) => {
        if (req.url === "/marketplace") {
          req.url = "/marketplace/";
        }
        next();
      });
    },
  };
}

One character — / — was the difference between a working app and a blank screen.

Layer 5: Asset references in index.html

<!-- apps/marketplace/index.html -->
<link rel="icon" href="/marketplace/favicon.png" />

Not /favicon.png. Not favicon.png. Must match the base path exactly. The favicon is the easy one to spot. The harder ones are Open Graph images, manifest files, and any hardcoded asset paths in your HTML.

The debugging principle

Sub-path apps fail silently. When something is misconfigured:

No 404 page (the proxy catches everything)
No console error (the HTML loads but contains nothing useful)
No network error (requests succeed, they just return the wrong content)

You get a blank white screen and have to check all five layers manually. We now have a checklist:

□ Vite base matches sub-path (with trailing slash)
□ React Router basename matches sub-path (without trailing slash)
□ Dashboard proxy rule exists for sub-path
□ Trailing slash redirect plugin is active
□ All index.html asset paths use the sub-path prefix
□ Hard refresh works (not just client-side navigation)

Integrating Feature Branches: The Wrong Way

With the marketplace working on the monorepo branch, we needed to bring in the outreach feature from feat/automated-outreach — 110 files, all referencing src/ paths.

What we tried first

Checked out feat/automated-outreach
Ran the migration script on it (moved files to apps/dashboard/src/)
Committed the migration
Merged feat/marketplace-integration into it

Result: 45 merge conflicts.

Both branches had independently run the migration script. Git saw every file that was moved from src/ to apps/dashboard/src/ as a conflict — because both branches created the same file at the same destination, even when the content was identical.

The resolution that silently broke everything

Under time pressure, we resolved all 45 conflicts by bulk-checking out files from the marketplace branch:

# "Quick" conflict resolution
git checkout feat/marketplace-integration -- packages/ui/src/components/button.jsx
git checkout feat/marketplace-integration -- packages/ui/src/components/card.jsx
git checkout feat/marketplace-integration -- apps/dashboard/src/features/campaign/constants/index.js
# ... 42 more files

The app started. No conflict markers. Looked clean.

Then at runtime:

SyntaxError: does not provide an export named 'getOutreachStatus'

What actually happened

git checkout <branch> -- <file> replaces the entire file with that branch's version. For shared UI components (button.jsx, card.jsx), this was fine — identical in both branches.

But campaign/constants/index.js was different. The outreach branch had added:

export const OUTREACH_AUTOMATION_STATUS = {
  NOT_STARTED: "not_started",
  ACTIVE: "active",
  PAUSED: "paused",
};

export const OUTREACH_REACHOUT_STATUS = {
  yet_to_reachout: {
    label: "Yet to Reachout",
    color: "text-slate-500",
  },
  reached_out_no_reply: {
    label: "Reached Out - No Reply",
    color: "text-amber-500",
  },
  // ...
};

export const getOutreachStatus = (status) =>
  OUTREACH_REACHOUT_STATUS[status] ||
  OUTREACH_REACHOUT_STATUS.yet_to_reachout;

The marketplace branch had the older version without these exports. By checking out the marketplace version, we silently deleted the outreach code. No warning. No error at merge time. The imports compiled fine because the file existed — it just didn't export what the outreach components expected.

We found similar silent deletions in:

Store file — outreach pagination state gone
Hooks file — outreach board columns gone
Creator list component — column management drawer gone
Workflow labels — outreach-specific labels gone

Total: 26 files with silently dropped code. All discovered only at runtime.

The lesson

Never bulk-resolve merge conflicts by checking out one side. It's the git equivalent of deleting files you haven't read. The correct approach depends on which branch owns each file:

Conflict type	Resolution
File exists only in branch A	Take A's version
File exists only in branch B	Take B's version
File modified in both branches	Read both versions, merge manually

And after resolving, always diff against both parents:

# Did we lose anything from the outreach branch?
git diff HEAD -- apps/dashboard/src/features/campaign/

# Did we lose anything from the marketplace branch?
git diff feat/marketplace-integration -- packages/ui/

Integrating Feature Branches: The Right Way

We scrapped the broken merge and started over. The approach that works:

Step 1: Start from the migrated base

git checkout -b feat/automated-outreach upstream/chore/monorepo-migration

This gives us the clean monorepo structure — apps/dashboard/, packages/ui/, all the Vite config — without any feature code.

Step 2: Get the feature PR's final file state

Instead of cherry-picking commits (which carry merge history and conflict potential), we extract the final state of every changed file:

# Fetch the PR
git fetch upstream pull/XXXX/head:pr-ref

# List all files the PR changed
gh pr diff XXXX --name-only
# → src/features/campaign/api/mutations/createProposalMutation.js
# → src/features/campaign/api/mutations/index.js
# → src/features/campaign/constants/index.js
# → ... (110 files total)

Step 3: Copy with path mapping

Every file in the PR uses src/ paths. We need them under apps/dashboard/src/:

gh pr diff XXXX --name-only | while read f; do
    [ "$f" = "package.json" ] && continue
    target="apps/dashboard/$f"
    mkdir -p "$(dirname "$target")"
    git show pr-ref:"$f" > "$target"
done

This copies the final version of each file — all 18 commits squashed into the end result — and places it in the monorepo structure.

Step 4: Fix imports

The copied files still have old-style imports. Run the verification script:

find apps/dashboard/src -type f \( -name "*.jsx" -o -name "*.js" \) \
  -exec sed -i '' \
    's|from "~/components/ui/\([^"]*\)"|from "@acme/ui/components/\1"|g' \
  {} +

# Revert excluded components
find apps/dashboard/src -type f \( -name "*.jsx" -o -name "*.js" \) \
  -exec sed -i '' \
    -e 's|from "@acme/ui/components/async-select"|from "~/components/ui/async-select"|g' \
    -e 's|from "@acme/ui/components/confirm-dialog"|from "~/components/ui/confirm-dialog"|g' \
  {} +

Step 5: Add new dependencies

The outreach feature introduced three new packages:

pnpm add --filter @acme/dashboard react-markdown remove-markdown turndown

Step 6: Commit and merge

git add apps/dashboard/ pnpm-lock.yaml
git commit -m "feat: add automated outreach feature to monorepo"

# Now merge the marketplace branch
git merge feat/marketplace-integration --no-edit

Result: zero conflicts.

The outreach commit added and modified files in apps/dashboard/src/features/campaign/. The marketplace branch added apps/marketplace/ and dashboard proxy config. No overlapping files.

Why this works

The key insight: don't migrate the feature branch. Apply the feature's changes directly onto the already-migrated base.

When you migrate two branches independently:

Base → Migration → Branch A (all files moved to apps/dashboard/)
Base → Migration → Branch B (all files moved to apps/dashboard/)
Merge A + B → 45 conflicts (same files created at same paths)

When you apply features onto the migrated base:

Base → Migration → Feature A applied → Feature B merged → 0 conflicts

The second approach treats migration as infrastructure and features as content. Infrastructure is shared (one copy). Content is separate (no overlap).

The Import Safety Net

Throughout this process — cherry-picks, merges, file copies — old-style imports kept reappearing. Every time code from a pre-migration branch enters the monorepo, some files will have:

import { Button } from "~/components/ui/button"; // broken

Instead of:

import { Button } from "@acme/ui/components/button"; // correct

We ran Step 24 of the migration script five times over the course of the integration. It's designed to be run repeatedly:

BROKEN=$(find apps/dashboard/src -type f \( -name "*.jsx" -o -name "*.js" \) \
  -exec grep -l 'from "~/components/ui/' {} + 2>/dev/null | \
  xargs grep 'from "~/components/ui/' 2>/dev/null | \
  grep -v "async-select" | grep -v "confirm-dialog" || true)

if [ -n "$BROKEN" ]; then
    # Fix and report
fi

Running it on already-fixed code is a no-op. Running it after a merge catches anything that slipped through. It's the cheapest safety net we have.

Treat migration as a gate, not a one-time event. Until every pre-migration branch is merged, this gate needs to exist.

The Complete Workflow

Here's the process we now follow for integrating any pre-migration feature branch:

# 1. Start from the migrated base
git checkout -b feat/my-feature upstream/chore/monorepo-migration

# 2. Fetch and extract the feature PR
git fetch upstream pull/XXXX/head:pr-ref
gh pr diff XXXX --name-only | while read f; do
    target="apps/dashboard/$f"
    mkdir -p "$(dirname "$target")"
    git show pr-ref:"$f" > "$target"
done

# 3. Fix imports
# (run Step 24)

# 4. Add new dependencies
pnpm add --filter @acme/dashboard <new-packages>

# 5. Commit
git add apps/dashboard/ pnpm-lock.yaml
git commit -m "feat: add <feature> to monorepo"

# 6. Merge other branches (zero conflicts expected)
git merge feat/other-branch --no-edit

# 7. Run Step 24 again (the merge may have brought old imports)

# 8. Verify
grep -r '~/components/ui/' apps/dashboard/src/ \
  --include='*.jsx' --include='*.js' \
  | grep -v 'async-select\|confirm-dialog'
# Should return nothing

What We Learned

Things that broke silently

Issue	Symptom	Time to diagnose
CSS imports ignoring `exports`	ENOENT on shared stylesheet	30 min
Firebase singleton under pnpm	"Service database is not available"	4 hours
Trailing slash in sub-path	Blank white screen, no errors	2 hours
`git checkout --theirs` dropping code	Missing exports at runtime	3 hours
Old imports after merge	Vite import analysis failure	10 min (once we had Step 24)

Things that could have been caught earlier

A pre-migration CI check: If we'd added grep -r '~/components/ui/' apps/dashboard/src/ to CI, broken imports would fail the build instead of reaching dev.
Firebase integration test: A simple test that calls getDatabase(app) would have caught the singleton issue immediately instead of us discovering it in the browser.
Sub-path smoke test: A curl to localhost:3002/marketplace checking for a 200 with non-empty body would have caught the trailing slash issue in seconds.

The production-level principles

pnpm breaks singleton libraries. Add resolve.dedupe for any library that shares state between sub-packages. This is invisible until runtime.
CSS tooling lives outside the module system. Use Vite aliases for shared packages that contain styles. exports won't help you.
Sub-path apps fail silently. Five layers must agree. Build a checklist and test with hard refresh.
Never bulk-resolve git conflicts. Read both sides. Diff against both parents after resolving.
Migration is ongoing. Until every old-structure branch is merged, keep the import verification script and run it after every merge.
Apply features onto the migrated base, not the other way around. This single decision turned 45 conflicts into zero.

Final State

my-app/
├── apps/
│   ├── dashboard/       # @acme/dashboard (port 3002)
│   └── marketplace/     # @acme/marketplace (port 3003, /marketplace)
├── packages/
│   └── ui/              # @acme/ui (shared shadcn/ui components)
├── scripts/
│   └── migrate-to-monorepo.sh
├── pnpm-workspace.yaml
├── turbo.json
└── package.json

One command starts everything:

$ pnpm dev

Two apps running, shared components, Firebase working, all feature branches integrated. The migration touched 500+ files across five branches. The final commit history is clean. The process is documented. And we have a script that catches the next engineer's old-style imports before they reach production.

That's the part the tutorials leave out — the migration isn't done when the script finishes. It's done when the last pre-migration branch merges and the safety net can finally be removed.

Turborepo + Vite with React Monorepo (Part 1)

Ashish Patel — Tue, 17 Feb 2026 06:51:29 +0000

This is Part 1 of a two-part series on migrating a production React app to a monorepo. This post covers the migration itself — the script, the structure decisions, and two invisible runtime bugs that only appear after you switch package managers. Part 2 covers integrating feature branches, adding a new sub-path app, and the merge strategy that saved us from 45-file conflict hell.

The Codebase

A production SaaS platform — React 18, Vite, Tailwind CSS, shadcn UI, Firebase Realtime Database, React Query, Zustand. Over 500 files, 30+ shadcn UI components, active development by multiple engineers.

Everything lived under one src/ directory:

acme-dashboard/
├── src/
│   ├── components/
│   │   ├── ui/           ← 30+ shadcn components
│   │   ├── AppSidebar/
│   │   ├── ProfileView/
│   │   └── ...
│   ├── features/         ← Feature modules
│   ├── pages/
│   ├── hooks/
│   ├── stores/
│   ├── contexts/
│   └── configs/
│       └── firebase-config.js
├── public/
├── vite.config.js
└── package.json

This worked fine until a second app needed the same shadcn components. Copy-pasting 30+ UI components across repos and keeping them in sync wasn't sustainable. We needed a shared package.

Why pnpm + Turborepo

We evaluated three setups:

Setup	Pros	Cons
npm workspaces	Zero config, familiar	Slow installs, phantom dependencies from hoisting
yarn berry (PnP)	Fast, strict	Breaks many packages, IDE support is flaky
pnpm workspaces + Turborepo	Fast installs, strict isolation, task orchestration	Singleton issues (we'll get to this)

pnpm won because of disk efficiency (content-addressable store), strict module isolation (no phantom dependencies), and speed. Turborepo added parallel task execution and caching on top.

The trade-off we didn't know about yet: pnpm's strict isolation would break Firebase in a way that produces zero warnings at install time and only fails at runtime. More on that later.

The Target Structure

acme-dashboard/
├── apps/
│   └── dashboard/          # @acme/dashboard
│       ├── src/
│       │   ├── components/ # Dashboard-specific components
│       │   ├── features/
│       │   ├── pages/
│       │   └── ...
│       ├── vite.config.js
│       └── package.json
├── packages/
│   └── ui/                 # @acme/ui
│       ├── src/
│       │   ├── components/ # Shared shadcn components
│       │   ├── styles/
│       │   └── lib/utils.js
│       └── package.json
├── scripts/
│   └── migrate-to-monorepo.sh
├── pnpm-workspace.yaml
├── turbo.json
└── package.json            # Root workspace config

Two decisions were made upfront:

Only shadcn UI components move to the shared package. Feature components, pages, stores — everything else stays in apps/dashboard/. Extracting too much creates coupling between the shared package and app-specific code.
Two components stay in dashboard even though they're in components/ui/. async-select depends on React Query hooks. confirm-dialog uses the app's toast system. Moving them would pull the entire app into packages/ui as a dependency.

The Migration Script

We wrote a 24-step bash script. Not because bash is the right tool — but because the migration is a one-time operation, and a script makes it reproducible. When three feature branches all need migration, running the same script ensures consistency.

Phase 1: Scaffold (Steps 1–10)

# Create workspace structure
mkdir -p apps/dashboard packages/ui/src/{components,styles,lib,hooks}

# Move app files
mv src/ apps/dashboard/src/
mv public/ apps/dashboard/public/
mv vite.config.js apps/dashboard/
mv index.html apps/dashboard/
# ... tailwind.config, postcss.config, etc.

Generate workspace config:

# pnpm-workspace.yaml
packages:
  - "apps/*"
  - "packages/*"

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "dev": { "persistent": true, "cache": false },
    "build": { "dependsOn": ["^build"], "outputs": ["build/**"] },
    "format": {},
    "lint": {}
  }
}

Phase 2: Extract Shared UI (Steps 11–20)

This is where the decisions matter. We move shadcn components but need to handle their dependencies:

# Move components
mv apps/dashboard/src/components/ui/* packages/ui/src/components/
# Keep the two that depend on app code
mv packages/ui/src/components/async-select.jsx apps/dashboard/src/components/ui/
mv packages/ui/src/components/confirm-dialog.jsx apps/dashboard/src/components/ui/

# Move shared utilities
mv apps/dashboard/src/lib/utils.js packages/ui/src/lib/
mv apps/dashboard/src/styles/global.css packages/ui/src/styles/

The shared package's package.json:

{
  "name": "@acme/ui",
  "private": true,
  "type": "module",
  "exports": {
    "./components/*": "./src/components/*",
    "./styles/*": "./src/styles/*",
    "./lib/*": "./src/lib/*"
  },
  "peerDependencies": {
    "react": "^18.0.0",
    "react-dom": "^18.0.0"
  }
}

We defined exports for correctness, but — spoiler — they won't be what actually resolves the imports. More on that in the next section.

Phase 3: Rewrite Imports (Steps 21–23)

Every file that imported from ~/components/ui/ needs to point to @acme/ui/components/:

find apps/dashboard/src -type f \( -name "*.jsx" -o -name "*.js" \) -exec \
    sed -i '' \
        -e 's|from "~/components/ui/\([^"]*\)"|from "@acme/ui/components/\1"|g' \
        -e "s|from '~/components/ui/\([^']*\)'|from '@acme/ui/components/\1'|g" \
    {} +

# Revert the two excluded components
find apps/dashboard/src -type f \( -name "*.jsx" -o -name "*.js" \) -exec \
    sed -i '' \
        -e 's|from "@acme/ui/components/async-select"|from "~/components/ui/async-select"|g' \
        -e 's|from "@acme/ui/components/confirm-dialog"|from "~/components/ui/confirm-dialog"|g' \
    {} +

Phase 4: Verify (Step 24)

This step exists because imports will break again — every cherry-pick, merge, or branch integration can reintroduce old-style imports:

BROKEN=$(find apps/dashboard/src -type f \( -name "*.jsx" -o -name "*.js" \) \
    -exec grep -l 'from "~/components/ui/' {} + 2>/dev/null | \
    xargs grep 'from "~/components/ui/' 2>/dev/null | \
    grep -v "async-select" | grep -v "confirm-dialog" || true)

if [ -n "$BROKEN" ]; then
    warn "Found broken ~/components/ui/ imports — fixing..."
    # ... same sed replacement as above
fi

This step is idempotent. Running it on already-fixed code changes nothing. We ended up running it five more times over the next week as branches merged in.

The First Invisible Bug: CSS Imports Don't Resolve Exports

After running the script and pnpm install, we started the dev server:

[postcss] ENOENT: no such file or directory, open '@acme/ui/styles/globals.css'

The import in apps/dashboard/src/styles/global.css:

@import "@acme/ui/styles/globals.css";

We'd set up exports in packages/ui/package.json to handle this. But CSS @import statements don't resolve through Node.js exports fields. PostCSS and Vite's CSS pipeline bypass the module system entirely. They look for the file on disk, following the package's main field or the literal path — never exports.

This is a fundamental gap. The exports field was designed for JavaScript modules. CSS tooling predates it and has no integration with it.

The fix

Skip exports for resolution and use a Vite alias:

// apps/dashboard/vite.config.js
resolve: {
    alias: [
        { find: "~", replacement: resolve(__dirname, "./src") },
        { find: "@acme/ui", replacement: resolve(__dirname, "../../packages/ui/src") },
    ],
}

The alias resolves @acme/ui/styles/globals.css to ../../packages/ui/src/styles/globals.css before the CSS pipeline ever sees it. Works for JS imports, CSS imports, and dynamic imports.

We kept exports in the package.json for documentation purposes, but the alias is what actually resolves everything.

The thing that trips people up: this only matters for packages that contain non-JS assets (CSS, images, fonts). Pure JS packages work fine with exports. The moment you share styles across workspaces, you need the alias.

The Second Invisible Bug: pnpm Breaks Firebase

The CSS fix let the dev server start. The app loaded to a white screen with this in the console:

Uncaught Error: Service database is not available
    at firebase-config.js:46:27

Line 46: export const realTimeDB = getDatabase(app);

Same code, same Firebase version, same config. The only change was the package manager.

The debugging journey

We started with the obvious — is firebase/database installed? Yes. Is app initialized? Yes. Is getDatabase imported correctly? Yes.

We added console logs:

const app = initializeApp(firebaseConfig);
console.log("App:", app.name); // "[DEFAULT]" ✓
console.log("App options:", app.options); // Full config ✓
const db = getDatabase(app); // 💥 Error

The app was initialized. The database just couldn't see it.

How pnpm isolates modules

npm and yarn use a flat node_modules/. Every package can see every other package. pnpm uses a virtual store — each package gets its own isolated dependencies:

node_modules/
├── .pnpm/
│   ├── @firebase+app@0.11.4/
│   │   └── node_modules/
│   │       └── @firebase/app/        ← copy A
│   └── @firebase+database@1.0.20/
│       └── node_modules/
│           └── @firebase/database/   ← can't see copy A
│               └── (no @firebase/app here)
└── @firebase/app/                     ← hoisted symlink

@firebase/database needs @firebase/app but doesn't declare it as a direct dependency (it's a peer dependency expected to be hoisted). In npm/yarn, hoisting makes it available everywhere. In pnpm, the package at .pnpm/@firebase+database@1.0.20/ can't traverse up to find the hoisted copy.

What Vite does with this

Vite's dev server resolves imports on the fly. When @firebase/database internally imports @firebase/app, Vite starts resolution from the database package's location in .pnpm/. It doesn't find @firebase/app there, so it tries... and either finds a different copy or fails silently by creating a new instance.

The result: two separate @firebase/app instances. Your code registers the Firebase app in instance A. @firebase/database looks for it in instance B. The registry is empty. "Service not available."

We confirmed this by checking the actual paths:

# Where does @firebase/database live?
realpath node_modules/.pnpm/@firebase+database@1.0.20/node_modules/@firebase/database
# → /Users/.../node_modules/.pnpm/@firebase+database@1.0.20/.../@firebase/database

# Can it see @firebase/app?
ls node_modules/.pnpm/@firebase+database@1.0.20/node_modules/@firebase/app
# → No such file or directory

# Where is @firebase/app actually?
realpath node_modules/@firebase/app
# → /Users/.../node_modules/.pnpm/@firebase+app@0.11.4/.../@firebase/app

Two completely isolated paths. No way for one to find the other.

The fix

Two Vite config options, both required:

// apps/dashboard/vite.config.js
resolve: {
    dedupe: ["@firebase/app", "@firebase/component"],
},
optimizeDeps: {
    include: [
        "firebase/app",
        "firebase/auth",
        "firebase/database",
    ],
},

resolve.dedupe: Forces Vite to always resolve @firebase/app and @firebase/component from the project root, regardless of where the import originates. One copy, one singleton, one registry.

optimizeDeps.include with firebase/database: Forces Vite to pre-bundle the database module during dev server startup. Pre-bundling respects the dedupe setting, so the pre-bundled database uses the same @firebase/app instance as everything else.

Without both, it doesn't work:

Config	Result
Only `optimizeDeps.include`	Pre-bundles each module separately → separate instances
Only `resolve.dedupe`	Dev server bypasses pre-bundling, resolves from `.pnpm` directly
`optimizeDeps.exclude: ["firebase"]`	No pre-bundling at all → `.pnpm` resolution → broken
Neither	Same as before migration broke it

This isn't just a Firebase problem

Any library that uses a global singleton pattern will break under pnpm + Vite if the internal packages don't declare proper peer dependencies. Libraries we've seen this affect:

Firebase (all services)
Some analytics SDKs that use a shared event bus
Auth libraries with global token stores
Any library where sub-packages need to share state via a common core

The fix is always the same: resolve.dedupe the core package + include the sub-packages in optimizeDeps.

Running the Migration

The complete migration checklist:

# 1. Run the script
bash scripts/migrate-to-monorepo.sh

# 2. Install dependencies (creates workspace symlinks)
pnpm install

# 3. Verify the Vite config has:
#    - @acme/ui alias
#    - Firebase dedupe
#    - Firebase in optimizeDeps.include

# 4. Start dev server
pnpm dev

# 5. Verify:
#    - App loads without white screen
#    - Firebase Realtime DB works (no "Service not available")
#    - All UI components render (no broken imports)
#    - CSS styles apply (shared globals.css loads)

If step 4 shows errors, the most common causes:

ENOENT on @acme/ui: Run pnpm install — the workspace symlink doesn't exist yet
"Service X is not available": Add the Firebase service to resolve.dedupe and optimizeDeps.include
Missing component: Run Step 24 again — an old import snuck through
CSS not loading: Check the Vite alias points to the right relative path

What We Ended Up With

// Root package.json
{
  "scripts": {
    "dev": "turbo dev",
    "dev:dashboard": "pnpm --filter @acme/dashboard dev",
    "build": "turbo build",
    "format": "turbo format"
  }
}

$ pnpm dev
# Starts dashboard on localhost:3002
# Turborepo orchestrates all workspace tasks in parallel

The dashboard works exactly as before — same features, same routes, same behavior. But now packages/ui is a shared dependency that any new app can import from. And that's exactly what we needed for Part 2, where we add a second app, integrate a 110-file feature branch, and learn why you should never merge two independently-migrated branches.

Next: Part 2 — Feature Branches, Sub-Path Apps, and the Merge Strategy Nobody Tells You About

Frontend Hiring Feels Broken

Ashish Patel — Tue, 16 Dec 2025 12:34:53 +0000

For years, I was on one side of the table giving frontend interviews.

Recently, I moved to the other side and started taking interviews as well.
That shift changed how I look at frontend hiring entirely.

A pattern kept repeating.

Candidates could confidently explain closures, promises, and array methods.
But when asked to build a real UI, things often started to fall apart.

Not because they were bad engineers.
But because we were testing the wrong things.

What Frontend Interviews Commonly Get Wrong

Most frontend interviews still heavily focus on:

Data Structures & Algorithms (DSA)
Abstract algorithmic puzzles
Problems that rarely appear in everyday frontend work

These questions do test logical thinking.
But they fail to measure UI engineering skills, which is where frontend engineers spend most of their time.

What Frontend Engineers Actually Do Day-to-Day

In real product teams, frontend engineers typically spend their time on:

Building clean, accessible, and responsive user interfaces
Managing state and asynchronous flows
Integrating APIs and handling imperfect, real-world data
Debugging tricky production issues
Thinking deeply about UX, performance, and edge cases

These are the skills that separate an average frontend developer from a great one.

Not how fast someone can reverse a linked list.

Why UI / Machine Rounds Are So Effective

This is where UI-focused or machine coding rounds shine.

Even a small task — such as building a form, a card layout, or an interactive component — reveals a lot:

How a candidate structures components
Their approach to state and data flow
Code readability and organization
Debugging mindset
Attention to UX and small details

In my experience, a 45-minute UI task often provides more signal than a 60-minute algorithm round.

DSA vs UI Rounds: Finding the Right Balance

DSA is not useless.

It helps assess:

Logical thinking
Problem-solving fundamentals
Backend-heavy or system-oriented roles

However, for UI-heavy frontend roles, DSA should support the hiring process, not lead it.

UI and machine coding rounds should be the primary filter.
Real-world frontend scenarios should drive hiring decisions.

Rethinking Frontend Hiring

If we want better frontend engineers, we need better frontend interviews.

That means:

Evaluating real UI skills
Simulating actual frontend work
Measuring how candidates think about UX, performance, and maintainability

Not just how well they perform in algorithm puzzles.

Final Thoughts

Frontend engineering is not “just JavaScript.”

It’s UI architecture, state management, user experience, performance, and product thinking — all working together.

Our interview processes should reflect that reality.

How does your team evaluate frontend engineers today?

I’d love to hear different perspectives in the comments.

Frontend Isn’t “Just UI” Anymore

Ashish Patel — Tue, 25 Nov 2025 10:22:00 +0000

For a long time, “frontend” sounded like a thin layer of buttons and CSS on top of the “real” application. Today, that picture is completely broken. Frontend is where product decisions surface, where performance is felt, and where user psychology either works for you or against you. All of that is happening inside a single render cycle. When someone taps a button or loads a page, they are judging not just your design but your product, your engineering, and your understanding of their needs.

That is why the biggest upgrade for modern frontend developers is not learning yet another framework. The real shift is learning to think in systems. Frameworks come and go, patterns trend and fade, but a systems mindset compounds across teams, codebases, and entire products.

Think in Systems, Not Screens

Most frontend pain is not because React or Vue or Svelte are “bad.” It comes from building isolated screens instead of coherent systems. When every feature is a one-off, you end up with duplicated logic, confused state, and fragile flows that are painful to change. Thinking in systems forces you to zoom out and design how pieces connect before you obsess over how they look.

A systems mindset on the frontend shows up in four habits:

Model data clearly, and half your bugs disappear. When your domain is well defined, your UI state stops being a random mix of flags and becomes a predictable reflection of real concepts.
Design for performance, and your UI finally feels premium. You naturally reach for techniques like memoization, streaming, pagination, caching, and lazy loading instead of shipping whatever loads first.
Align with user intent, and features start feeling “obvious.” The flow matches how users think, decide, and recover from mistakes, so the interface feels intuitive rather than “complex but powerful.”
Set clean boundaries, and your codebase stays calm as it grows. Components, hooks, services, and modules each have clear responsibilities, so new features feel like extensions, not surgeries.

With these in place, adding a new feature feels like plugging into a stable grid, not rewriting half the app.

Data Modeling: The Hidden Multiplier

On the backend, everyone understands that data modeling matters. On the frontend, it is often treated as an afterthought—until the state tree becomes unmanageable. The truth is that a huge amount of UI bugs are actually data modeling problems in disguise. When you do not know exactly what a “campaign,” “user,” or “session” looks like, the UI ends up making random guesses.

Clear frontend modeling means you use consistent shapes and types for the same concepts across the app. You know which fields are required, which are optional, and how entities relate. Changes in the product then become changes in the model first, and the UI follows. This not only prevents bugs but makes your code more readable, testable, and reusable across features.

Performance as Part of the Product

Users never say, “This bundle could use better code splitting,” but they absolutely feel laggy transitions, janky scroll, and spinners that never end. Performance is no longer a “nice to have” optimization for later; it is a core part of how your product is experienced. A fast interface feels trustworthy and thoughtful. A sluggish one feels broken, even if every request technically succeeds.

When you treat performance as a product concern, you design loading states, error states, and interaction flows deliberately. You choose the right rendering strategy for the use case—whether that is static generation, server-side rendering, streaming, or client-side hydration. You think in terms of perceived performance, not just numbers in a report. The result is a product that feels responsive, even when the underlying work is complex.

Psychology in Every Interaction

Modern frontend sits right where human psychology meets software. Every microcopy, color, animation, and layout decision nudges behavior in some direction. Good frontend engineering respects this. It recognizes that a confirmation dialog can reduce anxiety, a progress bar can reduce perceived wait time, and a clear empty state can turn confusion into clarity.

Aligning with user intent means understanding what someone is trying to do at each step and shaping the UI around that. Are they exploring, committing, editing, or recovering from a mistake? The frontend is the place where those states become real. When you design with intent, your features feel natural—not because they are trivial, but because they were built around how people actually think.

From Component Coder to Product Engineer

Anyone can learn how to write components. The real differentiator is understanding why things are done a certain way. Engineers who ask “Why is this flow designed like this?” or “What trade-off are we making here?” end up influencing product direction, not just closing tickets. They see the frontend as a living system that connects design, backend, business goals, and user behavior.

Frontend is not just evolving fast; it is evolving deeper. The surface area of tools will keep changing, but the depth of thinking is what turns a developer into an engineer and an engineer into a product partner.

So here is the question to leave you with: What is one mindset shift that actually made you a better frontend engineer—not just a faster one?

What’s New in React 19.2?

Ashish Patel — Fri, 03 Oct 2025 06:09:56 +0000

React 19.2, released in September 2025, is a feature-packed update focused on improving rendering performance, developer experience, and server-side rendering capabilities. For frontend engineers striving to build faster and more responsive applications, this release introduces several valuable additions worth exploring.

In this article, we'll walk through the highlights of React 19.2—including the new <Activity /> component, the useEffectEvent hook, enhanced profiling tools, and partial pre-rendering—and show you how these can help optimize your apps.

Key Features at a Glance

New capabilities in React 19.2:

<Activity /> component for fine-grained control over rendering and navigation speed
useEffectEvent hook to elegantly solve the common "stale closure" problem in effects
Partial pre-rendering APIs to serve static shells from CDNs and defer dynamic content hydration
Enhanced profiling with Performance Tracks integrated into Chrome DevTools
Smarter batching of Suspense boundaries in SSR for smoother hydration and transitions

The `<Activity />` Component: Smarter UI Visibility and Resource Management

The <Activity /> component introduces a powerful new way to manage UI visibility in your React applications. Unlike traditional conditional rendering that fully unmounts hidden components, <Activity /> preserves component state while pausing rendering and effects when components aren't visible.

Why This Matters

This pattern is especially valuable for:

Tabbed navigation where users frequently switch between views
Complex SPAs with multiple concurrent UI states
Performance-critical apps where you want to minimize unnecessary re-renders

When a component is hidden, it maintains its state without consuming rendering resources. When it becomes visible again, it resumes efficiently without needing to reconstruct its state from scratch.

Example: Building Efficient Tabs

import { useState } from 'react';
import { Activity } from 'react';

function Tabs() {
  const [activeTab, setActiveTab] = useState('home');

  return (
    <>
      <nav>
        <button onClick={() => setActiveTab('home')}>Home</button>
        <button onClick={() => setActiveTab('video')}>Video</button>
      </nav>

      <hr />

      <Activity mode={activeTab === 'home' ? 'visible' : 'hidden'}>
        <Home />
      </Activity>

      <Activity mode={activeTab === 'video' ? 'visible' : 'hidden'}>
        <Video />
      </Activity>
    </>
  );
}

With this approach, switching between tabs is instant and resource-efficient. The Video component maintains its playback position and state even when hidden, providing a seamless user experience.

Learn more: Activity Component Documentation

`useEffectEvent`: Solving the Stale Closure Problem

One of the most common pitfalls in React development has been the "stale closure" problem—when effect callbacks reference outdated props or state values. The new useEffectEvent hook provides an elegant solution by ensuring callbacks always access the latest values without requiring them in the dependency array.

The Problem It Solves

Previously, developers had to choose between:

Adding all dependencies to the effect array (causing unnecessary re-runs)
Omitting dependencies (risking stale closures and bugs)
Using workarounds like useRef (adding complexity)

How It Works

import { useEffectEvent, useEffect } from 'react';

function ChatRoom({ roomId, theme }) {
  const onConnected = useEffectEvent(() => {
    showNotification('Connected!', theme);
  });

  useEffect(() => {
    const connection = createConnection('wss://server', roomId);
    connection.on('connected', () => {
      onConnected();  // Always uses the latest theme value
    });
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]);  // Only roomId in dependencies
}

This pattern is invaluable for effects that define callbacks or event handlers, particularly for:

WebSocket event handlers
Timer callbacks
Subscription event listeners
Analytics tracking

Important: Only call useEffectEvent callbacks inside an effect. It's not a replacement for effect dependencies but a specialized tool for stable event handlers.

Learn more: useEffectEvent Hook Documentation

Partial Pre-rendering: Static Shells with Dynamic Hydration

React 19.2 introduces powerful APIs for partial pre-rendering, allowing you to pre-render static parts of your application while deferring dynamic content. This technique dramatically improves initial load times and Core Web Vitals metrics.

The Architecture

The workflow splits rendering into two phases:

Build/Server time: Pre-render static shells to HTML
Client time: Resume and hydrate only dynamic sections

This means your static content can be served instantly from a CDN while JavaScript loads and hydrates interactive elements in the background.

Implementation Pattern

import { prerender, resume, resumeAndPrerender } from 'react-dom/server';

// Pre-render app to 'prelude' and 'postponed' parts
const { prelude, postponed } = await prerender(<App />, {
  signal: abortController.signal,
});

// Serve prelude immediately (static HTML)
// ...

// Later, resume hydration for dynamic content
const resumedStream = await resume(<App />, postponed);

// Or combine both operations for static output
const { prelude: staticHTML } = await resumeAndPrerender(<App />, postponedState);

Benefits

Faster first paint by serving static HTML immediately
Improved Core Web Vitals (LCP, FID, CLS)
Better perceived performance as users see content instantly
Reduced JavaScript overhead by deferring non-critical hydration

This approach is particularly effective for:

Marketing pages with dynamic widgets
E-commerce sites with personalized sections
Content-heavy applications with interactive features
Large enterprise applications

Learn more: Partial Pre-rendering API Documentation

Enhanced Performance Profiling with Chrome DevTools

React 19.2 integrates seamlessly with Chrome DevTools through new Performance Tracks that provide unprecedented visibility into your application's rendering behavior.

What You Can Track

Scheduler Track shows task priorities and scheduling:

Blocking work (high priority)
Transition work (lower priority)
Task scheduling and execution timing

Component Track displays detailed rendering information:

Component render timings
Effect mount and unmount operations
Re-render causes and patterns

Using the Profiler

These tools help you:

Identify performance bottlenecks in specific components
Understand when and why components re-render
Optimize effect timing and dependencies
Diagnose slow transitions and interactions

The integration with Chrome DevTools means you can use familiar debugging workflows while getting React-specific insights.

Getting Started with React 19.2

Upgrading to React 19.2 is straightforward:

npm install react@19.2 react-dom@19.2

Migration Considerations

React 19.2 is designed to be backward compatible with most React 19.x applications. However, consider:

Testing new features in development before production deployment
Reviewing the official migration guide for any breaking changes
Gradually adopting new APIs like <Activity /> and useEffectEvent
Evaluating partial pre-rendering for performance-critical pages

Conclusion

React 19.2 represents a significant step forward in the evolution of React, providing developers with powerful tools to build faster, more responsive, and more maintainable applications. The combination of smarter rendering control through <Activity />, cleaner effect management with useEffectEvent, and advanced SSR capabilities through partial pre-rendering creates new possibilities for application architecture.

Whether you're building a complex SPA, optimizing an e-commerce platform, or creating a content-rich application, these features offer concrete solutions to common performance and developer experience challenges.

Ready to explore? Check out the official documentation and start experimenting with these features in your next React project. The community is excited to see what you build!

Additional Resources

The Ultimate React Hook Form + Zod Pattern for Reusable Create and Edit Forms

Ashish Patel — Thu, 25 Sep 2025 05:20:45 +0000

Forms in React have always given me a headache. Every time I started a new project, setting up validation and default values felt like juggling several balls at once. And don't even get me started on updating forms later—if I changed one thing, I had to hunt through multiple files just to make sure everything still worked.

Then I started building some complex forms for multi-platform score configurations (think: Instagram and YouTube scoring systems), and the complexity got out of hand pretty fast. I knew I had to fix how I managed form validation and defaults, or I'd lose my mind.

TL;DR: Bundle your Zod schema and default values in a single custom hook to handle both create and edit forms without duplication. Skip to the code examples below if you're impatient like me!

The Problem: Form Duplication Headaches

If you've worked with React forms for any length of time, this probably sounds familiar:

You create a form with validation
Later, you need an "edit" version of the same form
You copy most of your code but need to handle default values differently
A requirement changes, and you have to update both forms
You forget to update one of them, and bugs appear
Repeat until you question your career choices

I was tired of maintaining nearly identical form configurations across different components. Especially when using libraries like React Hook Form and Zod, it felt like I was duplicating effort for no good reason.

The Solution: Custom Schema Hooks

Here's a stripped-down version of what my solution looks like:

import { useMemo } from "react";
import { z } from "zod";

export const useProfileSchema = ({ data = {} } = {}) => {
  return useMemo(() => {
    // Define validation schema once
    const schema = z.object({
      username: z.string().min(1, { message: "Username is required" }),
      age: z.number().min(18, { message: "Must be at least 18" }),
      subscribe: z.boolean().default(false),
    });

    // Create defaults based on existing data or empty values
    const defaults = {
      username: data?.username || "",
      age: data?.age || 18,
      subscribe: data?.subscribe || false,
    };

    return { schema, defaults };
  }, [data]);
};

The magic happens with that data parameter. When creating a new form, you don't pass anything. When editing an existing record, you pass in the current values. The hook handles the rest!

Putting It To Work

Once I had this pattern down, setting up forms became a breeze. I just call this hook, plug its schema into React Hook Form via the resolver, and use the default values for initializing the form:

import { useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";
import { useProfileSchema } from "./useProfileSchema";

const ProfileForm = ({ initialData = {}, onSubmit }) => {
  const { schema, defaults } = useProfileSchema({ data: initialData });

  const form = useForm({
    resolver: zodResolver(schema),
    defaultValues: defaults,
  });

  return (
    <form onSubmit={form.handleSubmit(onSubmit)}>
      <div className="form-group">
        <label htmlFor="username">Username</label>
        <input 
          id="username"
          {...form.register("username")} 
          placeholder="Enter username" 
          className="form-control"
        />
        {form.formState.errors.username && (
          <span className="error">{form.formState.errors.username.message}</span>
        )}
      </div>

      <div className="form-group">
        <label htmlFor="age">Age</label>
        <input 
          id="age"
          type="number" 
          {...form.register("age", { valueAsNumber: true })} 
          placeholder="Enter age" 
          className="form-control"
        />
        {form.formState.errors.age && (
          <span className="error">{form.formState.errors.age.message}</span>
        )}
      </div>

      <div className="form-check">
        <input 
          id="subscribe"
          type="checkbox" 
          {...form.register("subscribe")} 
          className="form-check-input"
        />
        <label htmlFor="subscribe" className="form-check-label">
          Subscribe to newsletter
        </label>
      </div>

      <button type="submit" className="btn btn-primary mt-3">
        {initialData.id ? "Update Profile" : "Create Profile"}
      </button>
    </form>
  );
};

The beautiful part? This same component works for both creating and editing profiles. All you need to change is whether you pass initialData or not:

// Create new profile
<ProfileForm onSubmit={handleCreate} />

// Edit existing profile
<ProfileForm initialData={existingProfile} onSubmit={handleUpdate} />

Real-World Benefits

After implementing this pattern across several projects, here's what I've gained:

Single source of truth: Validation rules and defaults live together, so they never get out of sync
DRY code: No more copy-pasting form logic between create and edit pages
Easier maintenance: Need to change a validation rule? Do it once in the hook, not in multiple places
Better code organization: All form-related logic has a clear home
Smoother handoff: New team members can quickly understand how forms work in our codebase

Taking It Further: Advanced Patterns

For larger projects, I've extended this pattern in a few ways that have proven invaluable:

1. Adding TypeScript for Better Safety

Adding TypeScript definitions makes this pattern even more powerful:

// Define your schema type
type ProfileFormData = {
  username: string;
  age: number;
  subscribe: boolean;
};

export const useProfileSchema = ({ data = {} as Partial<ProfileFormData> } = {}) => {
  return useMemo(() => {
    const schema = z.object({
      username: z.string().min(1, { message: "Username is required" }),
      age: z.number().min(18, { message: "Must be at least 18" }),
      subscribe: z.boolean().default(false),
    });

    const defaults: ProfileFormData = {
      username: data?.username || "",
      age: data?.age || 18,
      subscribe: data?.subscribe || false,
    };

    return { schema, defaults };
  }, [data]);
};

2. Adding Transformation Functions

Sometimes the data from your API doesn't match exactly what your form needs. Adding transform functions to your hook can solve this:

export const useProfileSchema = ({ data = {} } = {}) => {
  return useMemo(() => {
    // Schema definition...

    // Transform API data to form format
    const apiToForm = (apiData) => ({
      username: apiData.user_name,
      age: apiData.user_age,
      subscribe: Boolean(apiData.newsletter_opt_in),
    });

    // Transform form data back to API format
    const formToApi = (formData) => ({
      user_name: formData.username,
      user_age: formData.age,
      newsletter_opt_in: formData.subscribe ? 1 : 0,
    });

    const defaults = data ? apiToForm(data) : {
      username: "",
      age: 18,
      subscribe: false,
    };

    return { schema, defaults, apiToForm, formToApi };
  }, [data]);
};

3. Supporting Conditional Validation

For more complex forms where validation rules change based on other fields:

export const usePaymentSchema = ({ data = {} } = {}) => {
  return useMemo(() => {
    const schema = z.object({
      paymentMethod: z.enum(["credit", "bank"]),
      creditCardNumber: z.string().optional(),
      bankAccountNumber: z.string().optional(),
    }).refine((data) => {
      if (data.paymentMethod === "credit" && !data.creditCardNumber) {
        return false;
      }
      if (data.paymentMethod === "bank" && !data.bankAccountNumber) {
        return false;
      }
      return true;
    }, {
      message: "Please fill in the required payment details",
      path: ["paymentMethod"],
    });

    // Rest of the hook...
  }, [data]);
};

4. Form Reset and Initial Values

One challenge I encountered was handling form resets properly. Here's a pattern that works well:

const ProfileForm = ({ initialData = {}, onSubmit }) => {
  const { schema, defaults } = useProfileSchema({ data: initialData });

  const form = useForm({
    resolver: zodResolver(schema),
    defaultValues: defaults,
  });

  // Reset form when initialData changes (useful in edit scenarios)
  useEffect(() => {
    form.reset(defaults);
  }, [initialData, form, defaults]);

  const handleReset = () => {
    form.reset(defaults);
  };

  return (
    <form onSubmit={form.handleSubmit(onSubmit)}>
      {/* Form fields... */}

      <div className="button-group">
        <button type="submit" className="btn btn-primary">
          {initialData.id ? "Update" : "Create"}
        </button>
        <button type="button" onClick={handleReset} className="btn btn-secondary">
          Reset
        </button>
      </div>
    </form>
  );
};

Performance Considerations

For larger forms, you might want to optimize your hook further:

export const useProfileSchema = ({ data = {} } = {}) => {
  // Memoize the data to avoid unnecessary recalculations
  const memoizedData = useMemo(() => data, [
    // Only include keys you care about
    data.username, 
    data.age, 
    data.subscribe
  ]);

  return useMemo(() => {
    // Schema and defaults logic
    return { schema, defaults };
  }, [memoizedData]); // Use the memoized data
};

Wrapping Up

Honestly, this small change made my workflow so much smoother. If you've ever felt frustrated juggling form state and validation across different files, give this pattern a shot. It saved me a lot of time and stress, and I bet it'll help you too.

The best part? This pattern works with any form library in React - not just React Hook Form. The principle of bundling schema and defaults in a custom hook is universally applicable.

What form patterns have you found useful in your React projects? Let me know in the comments!

Follow me for more React patterns and tips that make development smoother and more enjoyable. If this article helped you, consider sharing it with your team!

How useSyncExternalStore Transformed My React State Management

Ashish Patel — Wed, 24 Sep 2025 06:21:31 +0000

As a React developer, I’ve always been conscious of how I manage state, especially when integrating with external data sources or global stores. Over the years, I’ve used different patterns—useEffect hooks, custom subscriptions, and third-party libraries like Redux or Zustand. But recently, while working on a React 18+ project, I discovered useSyncExternalStore, and it genuinely changed my perspective on syncing external state with React components.

My Initial Pain Points with External Store Subscriptions

In one project, I needed to build a real-time dashboard listening to data from a custom in-memory store. Initially, I wrote the subscription logic using useEffect and useState. However, I ran into tricky bugs—sometimes the UI wouldn’t reflect the latest state correctly during fast updates, and in SSR scenarios, the server-rendered content didn’t always match the hydrated client UI.

The problem was subtle but frustrating. React’s concurrent rendering means components can render multiple times before committing, and the old subscription patterns weren’t designed for that.

Discovering `useSyncExternalStore`

When I came across React’s useSyncExternalStore hook, it was a lightbulb moment. This hook is created specifically to handle subscriptions to external “stores” safely with React 18’s concurrent features and supports server-side rendering.

It allows React to safely read a snapshot of external state and subscribe to updates, so UI stays consistent without race conditions or hydration mismatches.

How I Used It in My Project

I refactored my custom store and React component to use useSyncExternalStore like this:

// My custom store
let count = 0;
const listeners = new Set();

export const counterStore = {
  getSnapshot() {
    return count;
  },
  subscribe(callback) {
    listeners.add(callback);
    return () => listeners.delete(callback);
  },
  increment() {
    count++;
    listeners.forEach(listener => listener());
  },
};

And in React:

import React, { useSyncExternalStore } from "react";
import { counterStore } from "./counterStore";

function Counter() {
  const count = useSyncExternalStore(
    counterStore.subscribe,
    counterStore.getSnapshot,
    counterStore.getSnapshot // SSR fallback
  );

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={counterStore.increment}>Increment</button>
    </div>
  );
}

This switch made UI updates flawless—no more stale renders or mismatches. Updates were consistent and aligned perfectly with React 18’s rendering lifecycle.

Why This Matters for React Developers

Before this, I was tempted to keep using familiar patterns with useEffect for subscriptions, but these do not future-proof apps for the latest React features. SSR was especially complicated without snapshot fallbacks.

useSyncExternalStore solves these by:

Providing React the current snapshot during render.
Registering subscriptions safe for concurrent renders.
Offering a server snapshot for consistent SSR.

Other Use Cases I Tried

I also used useSyncExternalStore to track window width via a custom hook. It replaced my old useEffect based event listener pattern and handled SSR with a sensible default width fallback.

function useWindowWidth() {
  return useSyncExternalStore(
    (callback) => {
      window.addEventListener("resize", callback);
      return () => window.removeEventListener("resize", callback);
    },
    () => window.innerWidth,
    () => 1024 // default width for SSR
  );
}

Final Thoughts

Switching to useSyncExternalStore was a small change with a big impact on the reliability and maintainability of my React apps, especially with concurrent features and SSR becoming the norm.

If managing external subscriptions or custom global state today, I highly recommend exploring this hook. It’s already powering popular state libraries under the hood, so take advantage of it directly!

Hope my experience helps others avoid the pitfalls I ran into and build more resilient React apps.

Would love to hear how others are using this hook or challenges faced!

How to Debug Node.js Applications Like a Pro

Ashish Patel — Wed, 17 Jul 2024 05:01:26 +0000

After working with Node.js for several years, I've encountered and overcome numerous debugging challenges. This guide shares practical insights and techniques I've found effective. Whether you're new to Node.js or looking to refine your debugging skills, I hope these experiences prove useful.

Console Logging: A Starting Point

Most developers start with console logging, and it's still a useful tool in many situations:

function processUser(user) {
  console.log('Processing user:', user);

  if (user.age < 18) {
    console.log('User is under 18');
    return 'Too young';
  }

  console.log('User is adult, continuing...');
  // More processing...

  return 'Processed';
}

While effective for quick checks, this method can clutter your code. For more complex debugging, consider using the built-in Node.js debugger or IDE integration.

Leveraging the Node.js Debugger

The Node.js debugger is a powerful tool that's often underutilized. Here's how to get started:

node --inspect-brk my-script.js

Then open Chrome and navigate to chrome://inspect. This allows you to use Chrome DevTools to debug your Node.js application, which is particularly useful for inspecting variables and stepping through code.

IDE Integration: Streamlining the Process

Visual Studio Code offers excellent debugging capabilities for Node.js. A basic launch.json configuration that I've found useful is:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug Current File",
      "program": "${file}",
      "skipFiles": ["<node_internals>/**"]
    }
  ]
}

This setup allows you to debug the currently open file by pressing F5, which can significantly speed up the debugging process.

Handling Asynchronous Code

Debugging asynchronous code can be challenging. Using async/await has made this process more straightforward:

async function fetchUserData(userId) {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    const data = await response.json();
    return data;
  } catch (error) {
    console.error('Failed to fetch user data:', error);
    throw error;
  }
}

When debugging async functions, setting breakpoints inside both the try block and the catch block can provide valuable insights into the execution flow.

Memory Profiling

For performance issues, particularly memory leaks, heap snapshots can be invaluable:

const heapdump = require('heapdump');

function takeHeapSnapshot() {
  const filename = `heap-${Date.now()}.heapsnapshot`;
  heapdump.writeSnapshot(filename, (err) => {
    if (err) console.error('Failed to generate heap snapshot:', err);
    else console.log(`Heap snapshot written to ${filename}`);
  });
}

Analyzing these snapshots in Chrome DevTools can help identify memory issues.

Code Quality with ESLint

ESLint can catch many potential issues before they become runtime errors. A basic configuration that I've found helpful:

module.exports = {
  env: {
    node: true,
    es2021: true,
  },
  extends: 'eslint:recommended',
  rules: {
    'no-unused-vars': ['error', { argsIgnorePattern: '^_' }],
    'no-console': ['warn', { allow: ['warn', 'error'] }],
    'eqeqeq': ['error', 'always'],
  },
};

Running ESLint as part of your development workflow can prevent many common mistakes.

Advanced Debugging Techniques

Conditional Breakpoints: Useful for debugging specific conditions within loops or frequently called functions.
Logpoints: Allow adding temporary logging without modifying code, which is particularly useful in production environments.
Remote Debugging: Essential for debugging deployed applications:

   node --inspect=0.0.0.0:9229 app.js

Use SSH tunneling to connect securely from a local machine.

Best Practices

From my experience, these practices have proven most effective:

Structured Logging: Tools like Winston or Pino provide more detailed and easily searchable logs.
Type Checking: TypeScript or JSDoc can catch many errors at compile-time.
Comprehensive Testing: Well-written tests often reveal bugs before they reach production.
Modular Code: Smaller, focused modules are generally easier to debug and maintain.
Continuous Integration: Automated testing and linting on every code push helps catch issues early.

Debugging is an ongoing learning process. Each project brings new challenges and opportunities to refine these skills. I hope these insights prove helpful in your Node.js development journey.

Creating an Empty Orphan Branch in Git

Ashish Patel — Mon, 18 Mar 2024 05:30:03 +0000

In the world of software development, starting a new project often means creating a fresh branch from the main codebase. However, sometimes, you might want to start from scratch without carrying over any history or code from the main branch. This is where Git's "orphan" branches come into play. In this article, we'll explore how to create an empty orphan branch in Git, providing you with a clean slate for your new projects or ideas.

What is an Orphan Branch?

An orphan branch in Git is a branch that has no parent branch, meaning it doesn't contain any of the history from the main branch. This feature is particularly useful when you want to start a new project or test out new ideas without the baggage of the existing codebase.

How to Create an Orphan Branch

Creating an orphan branch is straightforward. Here's a step-by-step guide:

Create the Orphan Branch: Use the command

git checkout --orphan <branch_name>

to create a new orphan branch. Replace <branch_name> with the name of your new branch.

Clean the Working Directory: Execute

git rm -rf .

to remove all files from the current working directory. This ensures that the new branch starts completely empty.

Add New Files: Now, you can add any new files you want to include in your project.
Commit the Changes: Commit the new files to the repository with git commit -m "Initial commit".
Push the New Branch: Make the new branch available on the remote repository by using git push -u origin <branch_name>.

Conclusion

In conclusion, creating an empty orphan branch in Git is a powerful tool for developers looking to start a new project from scratch. By leveraging the "orphan" feature, you can ensure that your new project is completely independent of the main branch, allowing for a fresh start without the baggage of previous code or history. Whether you're embarking on a new project or testing out a new idea, an orphan branch offers a clean, isolated environment to work in.

So, the next time you're starting a new project, consider using Git's orphan branches to give yourself a fresh start. Happy coding!

The God Object Dilemma: Simplifying Software Complexity

Ashish Patel — Sat, 02 Mar 2024 07:13:10 +0000

Hey there! Today, let's talk about something that's a bit like finding a messy closet in your house – the "God object." Now, this isn't some divine entity; it's just a fancy name for a messy chunk of code in software development.

What's a God Object?

So, imagine you have this piece of code that seems to know and do everything in your program. It's like your all-knowing friend who tries to solve every problem, whether it's managing data or handling user interactions. But here's the catch – it's a nightmare to understand and work with.

Spotting the Signs:

How do you know if you've got a God object on your hands?

Does Everything: It tries to handle way too many things, like a superhero juggling too many tasks at once.
Everyone Depends on It: Other parts of your code rely too much on this one object, making it hard to change anything without causing chaos.
Messy Inside Out: Instead of neatly organizing its stuff, it exposes too much information and does too much, like a messy room with stuff strewn everywhere.
Testing Trouble: Testing it feels like trying to untangle a knot – it's complicated and often leads to more mess.

Why It Matters:

Having a God object in your code can cause some headaches:

Harder to Change: As your code grows, this big guy becomes even harder to understand and modify.
Limits Growth: It's like a roadblock to making your code better and adding new features because everything depends on it.
Leads to Debt: Ignoring it means you're racking up technical debt – like borrowing trouble from the future.

How to Fix It:

So, how do we deal with this code mess?

Break It Down: Split it into smaller, simpler parts that each do one thing well.
Loosen Dependencies: Make sure other parts of your code don't rely too heavily on it – they should be more independent.
Keep It Neat: Encapsulate its functions neatly so it's easier to understand and work with.
Test It Out: Make sure everything still works as it should by testing each part separately.

Wrapping Up:

The God object might seem like a big problem, but with a bit of patience and some cleanup, you can tame it. Just like tidying up a messy room, breaking down your code into smaller, simpler pieces can make your programming life a whole lot easier.

So, next time you're faced with a tangled mess of code, don't panic. Take a deep breath, roll up your sleeves, and start untangling – you've got this!

5 Powerful HTML Attributes That Don't Require JavaScript

Ashish Patel — Wed, 28 Feb 2024 04:14:43 +0000

Certainly! Here's a refined version with code examples for each attribute:

1. Spellcheck: This attribute ensures that the browser checks spelling within specific elements, such as input fields or text areas, without requiring JavaScript. It's particularly useful for forms or content where accuracy matters.

   <textarea spellcheck="true"></textarea>

2. Download: The download attribute allows users to download resources directly when clicking on a link. It's handy for providing downloadable content like images, documents, or media files without JavaScript.

   <a href="path/to/file.pdf" download>Download PDF</a>

3. Video Thumbnail (Poster): By using the poster attribute in the <video> element, you can specify an image to display as a placeholder before the video starts playing. This mimics the functionality of a video thumbnail, enhancing user experience.

   <video controls poster="path/to/thumbnail.jpg">
       <source src="path/to/video.mp4" type="video/mp4">
       Your browser does not support the video tag.
   </video>

4. Translate: Employing the translate attribute, you can specify whether an element's content should be translated when a webpage is translated into another language. Setting it to "no" preserves the original content, useful for brand names or specific terms.

   <h1 translate="no">Your Company Name</h1>

5. Autocomplete: The autocomplete attribute enables or disables autocomplete functionality for input fields, providing control over whether the browser should suggest previously entered values. This can enhance user convenience and streamline form submission.

   <input type="text" autocomplete="on">

If you'd like to show your support for my work, you can buy me a coffee through the following link: Buy Me a Coffee. Your generosity helps fuel my creativity and allows me to continue sharing valuable content. Thank you for your support!

Sources:

Spellcheck: MDN Web Docs - Spellcheck Attribute
Download: MDN Web Docs - Download Attribute
Video Thumbnail (Poster): MDN Web Docs - Poster Attribute
Translate: MDN Web Docs - Translate Attribute
Autocomplete: MDN Web Docs - Autocomplete Attribute

React 19: A Deep Dive into the Upcoming Major Release

Ashish Patel — Thu, 22 Feb 2024 05:14:44 +0000

The highly anticipated release of React 19 is drawing closer, promising a plethora of exciting new features and performance enhancements. In this article, we'll take a comprehensive look at what React 19 has in store for developers, exploring not only the headline features but also the intricate aspects that empower developers to create more performant, dynamic, and engaging user interfaces.

React Compiler

Originally a research project, the React compiler has evolved into a vital component of production at Instagram.com. This innovative tool addresses the issue of excessive re-rendering in React applications, a common pain point for developers. While traditional approaches like manual memoization techniques such as useMemo and useCallback have been effective, they can be cumbersome and error-prone.

The React Compiler takes a different approach, automatically optimizing code without compromising the core mental model of React. It leverages its understanding of both JavaScript and React's rules to safely rewrite code for efficiency. This can significantly improve rendering performance, resulting in smoother user experiences, especially in complex data visualization components that frequently re-render.

Action

A groundbreaking addition in React 19 is the introduction of Actions, enabling seamless integration of functions with DOM elements such as <form/>. With Actions, developers can effortlessly execute both synchronous and asynchronous operations, streamlining data submission management and state updates. This paradigm shift towards unified client and server data handling promises a more cohesive programming model across diverse environments, simplifying form interactions and data submissions.

<form action={search}>
  <input name="query" />
  <button type="submit">Search</button>
</form>

Server Components: Unleashing the Power of Server-Side Rendering

Slow initial page loads and SEO woes can be addressed with Server Components, a game-changer for React development. By rendering components directly on the server using Server Components, developers can deliver lightning-fast first impressions and boost search engine ranking. This is particularly beneficial for content-heavy applications or those that require high SEO performance.

Asset Loading: Ensuring a Seamless User Experience

Ever encountered flickering text or layout shifts while waiting for stylesheets or fonts to load? Asset Loading integrates Suspense with resource loading, ensuring a smooth and seamless user experience. For instance, consider a product page with high-resolution images. Asset Loading ensures the image is ready before displaying it, preventing jarring disruptions and creating a polished UI.

Document Metadata: Taking Control of Head Elements

Managing <title>,<meta>, and <link> tags across different environments can be challenging. Document Metadata offers a solution. For example, consider a blog post with a specific title and description. This built-in support works seamlessly in all scenarios, providing unified control over your document's head section, simplifying SEO management, and branding consistency.

Web Components: Bridging Frameworks

A long-awaited feature arrives! React 19 embraces Web Components, opening up a world of possibilities and facilitating collaboration across different frameworks. For instance, imagine using a popular date picker component built as a Web Component within your React app. This integration fosters a more unified development ecosystem and allows developers to leverage the best of both worlds.

Hooks: Enhancing the Toolkit

While no new core hooks are introduced in React 19, improvements have been made to existing ones. useMemo and useCallback now offer enhanced capabilities for fine-grained memoization, potentially reducing unnecessary re-renders. Additionally, useEffect provides more control over when effects run, allowing for cleaner and more efficient side effects management. Lastly, useImperativeHandle offers streamlined usage for creating ref-like objects within functional components.

Conclusion

React 19 isn't just an upgrade; it's a gateway to a more performant, dynamic, and engaging development experience. From the groundbreaking React Compiler to the seamless integration of Web Components, each feature empowers developers to create user interfaces that shine.

By actively participating in the development process and learning about these new features, developers can ensure their applications are future-proof and leverage the full potential of React 19. Stay tuned for further updates and dive deeper into the official blog post at React Blog for comprehensive documentation and code examples.

If you found this article insightful, please consider supporting it by giving it a clap or sharing it with your peers. Stay tuned for more enlightening articles on web development by following me.

DEV Community: Ashish Patel

Turborepo + Vite with React Monorepo (Part 2)

The Problem: Three Branches, One Migration

Adding a Second App to the Monorepo

The workspace setup

The five layers of sub-path configuration

The debugging principle

Integrating Feature Branches: The Wrong Way

What we tried first

The resolution that silently broke everything

What actually happened

The lesson

Integrating Feature Branches: The Right Way

Step 1: Start from the migrated base

Step 2: Get the feature PR's final file state

Step 3: Copy with path mapping

Step 4: Fix imports

Step 5: Add new dependencies

Step 6: Commit and merge

Why this works

The Import Safety Net

The Complete Workflow

What We Learned

Things that broke silently

Things that could have been caught earlier

The production-level principles

Final State

Turborepo + Vite with React Monorepo (Part 1)

The Codebase

Why pnpm + Turborepo

The Target Structure

The Migration Script

Phase 1: Scaffold (Steps 1–10)

Phase 2: Extract Shared UI (Steps 11–20)

Phase 3: Rewrite Imports (Steps 21–23)

Phase 4: Verify (Step 24)

The First Invisible Bug: CSS Imports Don't Resolve Exports

The fix

The Second Invisible Bug: pnpm Breaks Firebase

The debugging journey

How pnpm isolates modules

What Vite does with this

The fix

This isn't just a Firebase problem

Running the Migration

What We Ended Up With

Frontend Hiring Feels Broken

What Frontend Interviews Commonly Get Wrong

What Frontend Engineers Actually Do Day-to-Day

Why UI / Machine Rounds Are So Effective

DSA vs UI Rounds: Finding the Right Balance

Rethinking Frontend Hiring

Final Thoughts

How does your team evaluate frontend engineers today?

Frontend Isn’t “Just UI” Anymore

What’s New in React 19.2?

Key Features at a Glance

The <Activity /> Component: Smarter UI Visibility and Resource Management

Why This Matters

Example: Building Efficient Tabs

useEffectEvent: Solving the Stale Closure Problem

The Problem It Solves

How It Works

Partial Pre-rendering: Static Shells with Dynamic Hydration

The Architecture

Implementation Pattern

Benefits

Enhanced Performance Profiling with Chrome DevTools

What You Can Track

Using the Profiler

Getting Started with React 19.2

Migration Considerations

Conclusion

Additional Resources

The Ultimate React Hook Form + Zod Pattern for Reusable Create and Edit Forms

The Problem: Form Duplication Headaches

The Solution: Custom Schema Hooks

Putting It To Work

Real-World Benefits

Taking It Further: Advanced Patterns

The `<Activity />` Component: Smarter UI Visibility and Resource Management

`useEffectEvent`: Solving the Stale Closure Problem

Discovering `useSyncExternalStore`