Why Microsoft Is Retiring Yeoman: Introducing @microsoft/spfx-cli

/ Sudharsan K...

Part 1 of 5 in the SPFx CLI Series

If you have scaffolded a SharePoint Framework project in the last several years, you know the routine:

npm install @rushstack/heft yo @microsoft/generator-sharepoint --global
yo @microsoft/sharepoint

Three global installs. An interactive wizard. Peer dependency conflicts on every major SPFx release. And a wait of several months any time a template bug needed to be fixed.

That workflow is being replaced.

In March 2026, as part of the SPFx 1.23 release cycle, Microsoft published @microsoft/spfx-cli — a new, open-source, standalone CLI tool for scaffolding SharePoint Framework projects. As of May 2026, it is in pre-release (0.1.0-pre.3). The planned GA date is SPFx 1.25, targeted for September 2026.

This post covers the why: the four structural problems with the Yeoman-based approach that drove Microsoft to build something new, and what @microsoft/spfx-cli looks like at a high level.

The Problems with Yeoman

Microsoft’s decision to replace Yeoman is not a product preference. The official spfx-cli architecture document cites four specific structural problems.

1. Yeoman Is in Maintenance Mode

Yeoman was one of the most influential JavaScript tooling projects of its era. It popularized the concept of project generators and shaped how many modern CLIs work. But the project has been in maintenance mode since approximately 2022. From the architecture doc:

“The project is in maintenance mode, many of its transitive dependencies are outdated, and the ecosystem has largely moved on.”

This has practical consequences for SPFx developers. Every npm audit on a freshly scaffolded project returns warnings tied not to SPFx itself but to Yeoman’s legacy dependency tree: yosay, colors, update-notifier, yeoman-generator. These are not SPFx problems. They are inherited noise from a scaffolding tool that has not been actively developed in years.

Building the SPFx scaffolding experience on top of a maintenance-mode dependency is a structural liability — and it gets harder to justify with every passing year.

2. Closed-Source Templates

The generator package — @microsoft/generator-sharepoint — bundles its templates inside a closed-source npm package. This is not a technical requirement; it is an artifact of how Yeoman generators are structured. The effect is that the SPFx community has no way to inspect, report on, or contribute to the templates that every SPFx project starts from.

“The generator’s templates are bundled inside the closed-source generator package, which limits community feedback and contributions.”

This matters. Template correctness issues — wrong TypeScript configurations, outdated package versions, incorrect manifest fields — cannot be caught or fixed by community contributors. The only path is to file an issue and wait for a Microsoft release. With @microsoft/spfx-cli, the templates live in the open-source SharePoint/spfx GitHub repository, and community PRs are explicitly welcomed.

3. High Support Cost and Test Fragility

The generator carries a large test matrix that is difficult to validate manually. Every permutation of component type, framework, SPFx version, and Node version creates a new test scenario. The architecture doc notes that existing automated tests have correctness issues and require a complex environment setup.

“The generator has a large test matrix that is difficult to test manually, has correctness issues in existing automated tests, and requires a complex environment setup.”

This is not something most developers see directly. But it has downstream effects: bugs that are hard to reproduce, fixes that require significant internal validation effort before shipping, and slower iteration on the scaffolding experience overall.

4. Coupled Release Cadence

Perhaps the most consequential structural problem: any change to a template required a full SPFx release. SPFx major versions ship roughly every three months. That means a template bug — a missing file, an incorrect configuration, a deprecated API — could sit unfixed for up to a quarter year.

“Template changes cannot ship without a full SPFx release, which slows iteration and prevents out-of-band fixes.”

With @microsoft/spfx-cli, templates are not bundled in the CLI. At runtime, the CLI fetches a ZIP archive from the GitHub repository. Bug fixes in templates ship immediately — without requiring a new CLI version, without requiring users to update their global install.

What @microsoft/spfx-cli Is

@microsoft/spfx-cli is a standalone npm CLI with two commands in its current pre-release form:

  • spfx create — Scaffold a new SPFx component
  • spfx list-templates — List all available templates

Installation is a single command:

npm install -g @microsoft/spfx-cli

No Yeoman. No yo global. No @rushstack/heft global. One tool.

Open-Source Templates

The templates are maintained in the SharePoint/spfx GitHub repository under an MIT license. They are not bundled in the CLI package. When you run spfx create, the CLI fetches the latest templates from GitHub at runtime. This means template fixes ship without a CLI update, the community can inspect and contribute to templates, and you can pin to a specific SPFx version’s templates with --spfx-version.

Non-Interactive by Design

@microsoft/spfx-cli has no interactive prompts. Every parameter is a CLI flag. This is a deliberate design decision oriented toward CI/CD and automation:

spfx create \
  --template webpart-react \
  --library-name my-spfx-library \
  --component-name "Hello World"

For developers who prefer the guided wizard experience, this is a change. For platform engineers and DevOps teams who automate scaffolding in pipelines, it is a significant improvement.

Custom and Org Templates

Teams can host their own template repositories and point the CLI at them using --remote-source. This is functionality the Yeoman generator never supported. Enterprise teams can maintain standardized, opinionated templates that reflect their own architecture patterns — and the CLI can scaffold from them directly.

Programmatic API

For teams building custom tooling, @microsoft/spfx-template-api exposes the rendering engine as an SDK. This opens the door to integrating SPFx scaffolding into editors, pipelines, and other developer tools.

Current Status (as of May 2026)

@microsoft/spfx-cli is in pre-release. The current version is 0.1.0-pre.3, published April 7, 2026. The tool was first introduced as a preview in the SPFx 1.23 release cycle (March 2026).

  • --version flag not yet implemented (issue #237)
  • JSON output mode for spfx list-templates not yet available (issue #235)
  • Adding components to existing projects (merge helpers) is in Phase 2 — not available in pre-release

The planned GA milestone is SPFx 1.25, targeted for September 2026. After GA, the Yeoman generator will receive a final update, and @microsoft/spfx-cli becomes the primary recommended scaffolding tool. The tool is pre-release, but it is stable enough to explore and use for new project scaffolding today.

What This Means for Developers Today

Solo developer or small team: You can start using @microsoft/spfx-cli for new projects today. The webpart-react, extension-listviewcommandset, and ACE templates are all available. For adding components to existing projects, the Yeoman generator remains the current path until merge helpers land in Phase 2. No existing Yeoman-scaffolded projects need to change anything.

Platform engineer or tech lead: Now is the right time to evaluate @microsoft/spfx-cli for your internal tooling. Custom template support and CI/CD integration are significant capabilities that the Yeoman generator never offered. Plan for Yeoman end-of-life after SPFx 1.25 (September 2026) in any long-term toolchain decisions.

Enterprise SPFx teams: The --remote-source flag and @microsoft/spfx-template-api SDK are worth exploring now. Building org-standard templates while the tool is in pre-release means you will be ready to move quickly at GA.

Next in This Series

The next post is a hands-on getting-started tutorial: installation, all 17 available templates, the full spfx create flag set, and a walkthrough from install to npm run build.

  • Part 2: Getting Started with @microsoft/spfx-cli
  • Part 3: Yeoman vs. @microsoft/spfx-cli — The Complete Developer Comparison
  • Part 4: Custom Templates and CI/CD with @microsoft/spfx-cli
  • Part 5: The Future of SPFx Scaffolding — Roadmap and What’s Next

Resources

Leave a Reply