The Dev Loop Problem

Before local dev tooling, iterating on an LWC component meant:

  1. Edit the component.
  2. Deploy to scratch org via sf project deploy start.
  3. Refresh the org.
  4. Test.
  5. Repeat.

A round trip of 30–90 seconds per change. Multiplied over a day, hours of wait time.

LWC Local Development runs a local dev server that renders and hot-reloads components as you save. The updated version (LWC Local Development 2.0, successor to the first-gen tool) improves speed, feature parity, and stability.

Installing

Install as a Salesforce CLI plugin:

sf plugins install @salesforce/plugin-lightning-dev

Verify:

sf lightning dev --help

Starting the Dev Server

From your DX project root:

sf lightning dev app --target-org MyScratchOrg

The command:

  • Starts a local dev server.
  • Opens a browser to the local URL.
  • Authenticates to your scratch org to pull org-specific data and metadata.
  • Watches your LWC source files for changes.

Edit a component; the browser hot-reloads within a second.

What Works Locally

  • Component rendering with real org metadata.
  • @wire with Apex methods from the org.
  • LDS (Lightning Data Service) calls — getRecord, getRelatedListRecords, etc.
  • Platform events (in some configurations).
  • Most lightning-* base components.

The tooling renders components in a local environment that proxies to the scratch org for data.

What Doesn’t Work Locally

  • Certain advanced Lightning App Builder page configurations.
  • Some ISV/managed package component embeddings.
  • Experience Cloud site-specific rendering may have limits.
  • Specific enterprise features (shield encryption, certain certification contexts).

When a component doesn’t render correctly locally, deploy to the org and verify. The gap is narrowing but hasn’t fully closed.

Common Workflow

Typical day for an LWC developer using local dev:

  1. sf org create scratch — set up a scratch org (once per week or as needed).
  2. sf project deploy start — seed it with your source.
  3. sf lightning dev app — start the dev server.
  4. Code, save, see changes instantly in the browser.
  5. Periodically deploy to scratch org for integration testing.
  6. Commit and push when ready.

The flow feels like modern SPA development — because that’s what it’s mimicking.

Debugging

Browser DevTools work normally. Set breakpoints, inspect state, look at network calls.

Source maps map bundled code back to your LWC source. Debugging feels like debugging the original files.

Hot Module Replacement (HMR) preserves component state across some reloads. When a reload breaks state, just refresh.

Tips for Faster Iteration

Keep your scratch org warm. Creating a new scratch org takes minutes. Use one for several days of work.

Seed sample data. sf org create scratch with an automatic setup script that creates sample records means your dev server has data immediately.

Run ESLint on save. VS Code’s LWC extension catches errors before runtime. Configure lint-on-save in your editor.

Watch for stale caches. Occasionally after a manifest change, restart the dev server. Most hot reloads work; not all do.

Compared to Deploying Every Change

Before LWC Local Dev:

  • 30–90 seconds per change.
  • Around 50–100 round trips per day.
  • 25–80 minutes lost to deploy wait time.

After:

  • Sub-second reloads.
  • 0 minutes on round trips.
  • More iterations per hour, more confidence per commit.

This is the most impactful tooling improvement of the last few years for LWC developers. If you haven’t adopted it, adopt it this week.

Gotchas

First request is slower. Initial render pulls metadata from the org. Subsequent renders are fast.

Org session refresh. If your scratch org session expires during a long dev session, the dev server catches it but prompts for re-auth.

Network variability. Remote scratch org calls add latency to data fetches. Local mocks help for pure UI work.

Component-library version mismatches. Keep the local dev plugin updated. Mismatches between local and org versions can cause surprising rendering differences.

Testing Alongside Local Dev

Local dev accelerates iteration but doesn’t replace tests. Keep:

  • Jest unit tests (@salesforce/sfdx-lwc-jest) for components.
  • Apex tests for server-side code.
  • End-to-end tests (UTAM, Playwright) for critical flows.

Run tests before deploys, not while the dev server is running. Separate concerns.

Integrations With CI/CD

Local dev is dev-only. CI uses:

  • sf project deploy validate for deployment validation.
  • sf apex run test for Apex tests.
  • sf test run for LWC Jest tests (via npm scripts).
  • sf flow test run for flow tests.

Local dev speeds the inner loop; CI handles the outer loop.

Frequently Asked Questions

Does local dev work on Windows?

Yes. The tooling is cross-platform (Mac, Linux, Windows).

Can I use it with a production-like sandbox instead of scratch org?

Scratch orgs are the recommended target — they’re isolated and disposable. Sandboxes work but risk impacting shared data.

How much does local dev cost?

The tooling is free. Scratch org usage counts against your Dev Hub allocation.

Does it support Aura components?

LWC Local Dev is for LWC. Aura components require deploy-to-org for visual testing.

Share