Part 3 of 5 in the SPFx CLI Series

@microsoft/spfx-cli is in active development and approaching GA. If you are an SPFx developer evaluating whether to switch from the Yeoman generator, this post gives you the full picture — without spin in either direction.

Both tools scaffold SharePoint Framework projects. They produce structurally identical output. But they are built on fundamentally different assumptions about how scaffolding should work, and those assumptions matter depending on how and where you build SPFx solutions.

As of May 2026, @microsoft/spfx-cli is in pre-release (0.1.0-pre.3). This comparison is based on the current state of the tool.

The Workflow Before and After

Before: Yeoman (current default)

# Step 1: Install three global packages
npm install @rushstack/heft yo @microsoft/generator-sharepoint --global
# Step 2: Run the interactive generator
yo @microsoft/sharepoint
# Step 3: Navigate prompts (component type, name, framework, etc.)
# ...several minutes of interactive input...

Three global installs. One interactive session. No practical way to automate in a pipeline without piping answers to stdin.

After: @microsoft/spfx-cli

# Step 1: Install one global package
npm install -g @microsoft/spfx-cli
# Step 2: Scaffold with flags
spfx create \
  --template webpart-react \
  --library-name my-spfx-lib \
  --component-name "Hello World"

One global install. One deterministic command. Fully scriptable.

The Full Comparison

What You Gain

Open-Source, Inspectable Templates

Every template in @microsoft/spfx-cli lives in the SharePoint/spfx GitHub repository under MIT license. You can inspect the template source for any generated file, understand exactly how a web part or extension is scaffolded, file issues against specific template content, and submit pull requests for improvements.

With @microsoft/generator-sharepoint, the templates are bundled inside a closed npm package. There is no way to review the template source without decompiling the package.

Template Fixes Without Waiting for a Release

When the CLI fetches templates at runtime from GitHub, a bug fix in a template ships immediately. The next spfx create will use the corrected template without requiring any CLI update.

With Yeoman, a template bug fix required a full SPFx release — a cycle that runs approximately every three months. Teams that hit a scaffolding bug had to work around it manually until the next major release.

Scriptable Scaffolding for Pipelines

@microsoft/spfx-cli is flag-only. Every parameter the generator wizard asked for is now a CLI flag. This makes scaffolding composable in shell scripts, GitHub Actions workflows, and other CI environments:

SPFX_CI_MODE=1 spfx create \
  --template webpart-react \
  --library-name pipeline-lib \
  --component-name "Automated WP" \
  --package-manager npm

The SPFX_CI_MODE=1 environment variable enables deterministic UUID generation — important for reproducible builds in automated environments.

Custom Org Templates

The --remote-source flag allows teams to point the CLI at their own GitHub-hosted template repository:

spfx create \
  --template acme-standard-webpart \
  --library-name portal-webpart \
  --component-name "Employee Directory" \
  --remote-source https://github.com/acme-corp/spfx-templates

This was never possible with Yeoman. Enterprise teams can now maintain their own opinionated, standards-compliant SPFx templates and scaffold from them with the same CLI their developers already use.

Cleaner npm Audit Results

The legacy Yeoman generator carries transitive dependencies that generate npm audit warnings on every new project: yosay, colors, update-notifier, yeoman-generator. These are not SPFx vulnerabilities — they are scaffolding tool dependencies that appear in the installed toolchain.

@microsoft/spfx-cli is built on the RushStack ecosystem. Its dependency footprint is smaller, and npm audit results on freshly installed projects are significantly cleaner.

What You Temporarily Give Up

Being honest about this matters. @microsoft/spfx-cli is pre-release and two features that Yeoman developers rely on are not yet available.

No Interactive Wizard

The Yeoman generator provides a step-by-step interactive prompt experience. For developers new to SPFx, this guided flow is helpful — it surfaces available options and prevents invalid combinations.

@microsoft/spfx-cli has no interactive mode. You need to know the template name and provide all required flags. The spfx list-templates command surfaces available template names, but there is no guided selection flow.

This is a trade-off by design. The interactive wizard is incompatible with CI/CD automation. The current tool prioritizes scriptability over guided discovery.

No “Add Component to Existing Project” Support

yo @microsoft/sharepoint can be run inside an existing SPFx project to add a new web part, extension, or library component to it. This is a common workflow — create a solution once, add components as requirements grow.

@microsoft/spfx-cli does not support this yet. Merge helpers (which will enable adding components to existing projects) are part of the Phase 2 roadmap and are targeted for the GA release in September 2026.

Until merge helpers land, use yo @microsoft/sharepoint when you need to add to an existing project.

When to Stick with Yeoman (for Now)

Use the Yeoman generator if any of these apply to your situation:

1. You need to add components to an existing project. Merge helpers in @microsoft/spfx-cli are not available yet. The Yeoman generator handles this reliably.
2. Your team relies on the interactive wizard. If guided prompts are important for onboarding new SPFx developers or for discovery, the Yeoman workflow is still the right choice.
3. You are in a tightly controlled environment. If upgrading tooling mid-project is a change management concern, maintaining the known Yeoman workflow until GA (September 2026) is the lower-risk path.

The Yeoman generator continues to be supported. Microsoft has stated it will receive a final update after SPFx 1.25. There is no pressure to switch before the tooling is right for your workflow.

When @microsoft/spfx-cli Is the Better Choice Today

Switch to @microsoft/spfx-cli for new projects if any of these apply:

1. You are building CI/CD pipelines that scaffold SPFx projects. The flag-based API is the right tool for automation.
2. Your team wants custom or org-specific templates. --remote-source is unique to @microsoft/spfx-cli.
3. You are building platform tooling or internal CLIs on top of SPFx scaffolding. The @microsoft/spfx-template-api SDK is not available in Yeoman.
4. You want to get ahead of the GA migration. September 2026 is not far away. Starting new projects with @microsoft/spfx-cli now means your team is already comfortable with the tool when Yeoman reaches end-of-life.

Summary

@microsoft/spfx-cli is architecturally the better tool for most modern SPFx development scenarios. It is more open, more scriptable, and more maintainable than the Yeoman generator. The current limitations — no interactive wizard, no add-to-existing — are known gaps with planned solutions in the roadmap.

For teams starting new projects today, especially in CI/CD or enterprise environments, @microsoft/spfx-cli is the recommended path. For teams that depend on yo @microsoft/sharepoint for existing-project workflows, hold the current toolchain until Phase 2 lands.

Next in This Series

• Part 4: Custom Templates and CI/CD with @microsoft/spfx-cli
• Part 5: The Future of SPFx Scaffolding — Roadmap and What’s Next

Resources

• GitHub: https://github.com/SharePoint/spfx
• Short URL: https://aka.ms/spfx/cli
• npm: https://www.npmjs.com/package/@microsoft/spfx-cli
• Docs: https://learn.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/sharepoint-framework-cli