The New SPFx CLI and Overhauling SharePoint Development for AI

The critical milestones from the SPFx 1.23 preview in May to the last version of SPFx Yeoman generator in September 2026. SPFx CLI will take over the scaffolding after this release.

Welcome back to Mastering Microsoft 365 and Beyond. Over the l/ast two editions we have been deep in the AI layer of the SharePoint stack. We covered Authoritative Sites, the feature that lets you designate specific SharePoint sites as trusted, high-priority knowledge sources so that Copilot draws answers from the content that actually matters in your organization, not whatever happens to rank highest. Then we went into Copilot in SharePoint itself, the opt-out rollout landing in mid-June 2026, the three-pillar framework of Know, Act, and Produce, the Agent Assets library, and what all of it means for governance before you flip the switch and enable the context-aware Copilot action button. If you missed either of those, I recommend going back, because this edition sits in the same AI layer.

Today we are talking about how SharePoint Framework solutions get built. Specifically, Microsoft has shipped a replacement for the scaffolding tool SPFx developers have used for nearly a decade. The new open-source command-line tool, the SPFx CLI (@microsoft/spfx-cli), replaces the old Yeoman generator (yo @microsoft/sharepoint). It is currently in pre-release and is architecturally different from its predecessor. It is also on a confirmed roadmap to become the only supported scaffolding path by September 2026.

What is Scaffolding?

Transitioning from the legacy, tightly coupled Yeoman generator to a cloud-aware, repository-first scaffolding model. With the new CLI, you publish your templates to any GitHub repository and point developers at it with — remote-source.

Before I get into the SPFx CLI, let’s take a step back for those not familiar with SharePoint development. This topic comes with plenty of jargon, so it’s worth laying a plain-language foundation. The timing of this SPFx update is more meaningful than it might appear, especially as it arrives during a time when Microsoft is transforming SharePoint into the enterprise knowledge hub for Copilot and Microsoft AI in Microsoft 365. I’ll get into more details on that later. The SharePoint Framework, or SPFx, is Microsoft’s official model for building custom components that run within SharePoint and Microsoft 365. When organizations need more than the standard built-in features, SPFx is usually the top choice. These components run in the browser, follow SharePoint’s permission model, and integrate smoothly into the Microsoft 365 experience, from SharePoint pages and Teams tabs to Viva Connections dashboard cards and, increasingly, the AI layer.

With that said, scaffolding is the process of generating the starting structure of one of those SPFx development projects. Rather than creating dozens of files and folders from scratch (e.g. configuration files, TypeScript source files, build tool setup, package manifests), a scaffolding tool generates all of it from a template. You tell it what kind of component you are building and what it should be called, and it produces a ready-to-develop project with everything wired up correctly for that component type and that version of SPFx.

It gives you the skeleton to start writing business logic immediately, rather than spending time configuring a build chain you did not design.

The Problem with the Yeoman Generator

The SPFx CLI decouples the scaffolding engine from project templates, enabling runtime updates without toolchain reinstalls.

For nearly a decade, SPFx developers ran yo @microsoft/sharepoint to start a new project. Yeoman is a general-purpose scaffolding system for Node.js, and Microsoft built and maintained a generator on top of it. But it had a structural problem that only got worse as SPFx expanded.

The core issue was tight coupling.

The templates were bundled inside the generator package. Every time the SPFx team fixed a bug in a template, added a new component type, or needed to ship a template targeting a release candidate, they had to publish a new version of the generator. You had to update the tool to get the templates. Developers working in organizations with locked Node environments, slow internal change management, or approval-gated npm installs were perpetually behind, and the SPFx team had no way to ship template improvements independent of the generator release cycle.

This problem compounded as SPFx grew.

When Adaptive Card Extensions were introduced and the template library expanded to cover multiple card types and framework variants, the generator became a larger and more complex artifact to maintain. Additionally, when release candidates started shipping faster and organizations needed to track preview features, the coupling between tool and templates meant every template update required a full generator release.

The new CLI solves this at the architecture level. Templates are fetched at runtime from the SharePoint/spfx GitHub repository. Keep reading to find out more.

Introducing @microsoft/spfx-cli and @microsoft/spfx-template-api

[embed]

This demo introduces the new SPFx CLI for scaffolding SharePoint Framework solutions. Alex Terentiev and Vesa Juvonen show how the CLI works.

The new SPFx CLI solves the tight-coupling problem at the architecture level and transforms SPFx development by decoupling the scaffolding engine from project templates. The CLI fetches templates at runtime directly from the SharePoint/spfx GitHub Repository. A new component type targeting a release candidate is available the same day the branch is pushed, without touching the CLI release at all. This allows Microsoft to ship template fixes and preview component types on the same day they are pushed, without requiring a CLI update. A template fix merges to main and is available immediately. That is how it should have been designed from the beginning. The tool and the content it delivers are finally separate concerns.

The new CLI architecture

• Running spfx create pulls the latest files from the repository at runtime, which in turn helps ensure your scaffolded projects reflect the newest community-backed standards.
• The CLI acts as an independently versioned executable, meaning the tool and the code it generates are finally separate concerns.
• The current template set covers everything the old generator supported, all of which are organized into four categories. All default to SPFx 1.22 and use — spfx-version to target a different release branch.

Microsoft’s Roadmap for the SPFx CLI

Navigating the transition window from community-driven templates in June to full General Availability this fall.

The urgency around the new CLI is about where the SPFx platform is going and how quickly. Microsoft’s Vesa Juvonen’s May 2026 roadmap update set the timeline.

SPFx 1.23 reached general availability in May 2026. This release focused on platform stability and modernization and included the first official preview of the new CLI as a highlighted feature. It also open-sourced the SPFx solution templates on GitHub for community contributions. The release notes describe it deliberately as “Preview of the new SPFx CLI, which will evolve how solutions are created and managed, moving towards a more flexible and open model with community-driven templates.” That phrase, community-driven templates, is the key in the release notes. Microsoft has opened the template layer to the community in a way the Yeoman generator never allowed. This allows the development ecosystem to build and distribute its own template sets, and moves the CLI from “Microsoft ships templates” to “anyone can ship templates.” Partners, ISVs, and individual organizations can now publish and maintain their own template libraries using the same infrastructure the CLI already supports.

Version 1.23.1, scheduled for this month (June 2026), introduces the ability to override the new and edit form panel in Microsoft Lists and SharePoint lists with SPFx components, along with the usual round of npm audit fixes. A focused but practical update that extends SPFx customization deeper into the list experience.

Version 1.24, also set for release in June 2026, moves a currently undisclosed feature (referred to in the roadmap as “Feature X”) to public preview. While details remain under wraps, the roadmap positions it alongside the broader AI extensibility investments landing in SPFx this year. It is described as a way to help developers create Copilot-ready, AI-enhanced apps and make it easier to integrate solutions with Microsoft 365 data and services, similar to what the Work IQ and Copilot APIs already offer in beta.

Version 1.25, targeted for September 2026, marks the general availability of the SPFx CLI. The Yeoman generator ships its last update alongside this release. After 1.25, the Yeoman path is effectively retired and the CLI becomes the scaffolding path for all new SPFx development. That is a roughly three-month window from today.

React 18 support originally targeted for June 2026 remains in active development but is not confirmed on the June schedule. Navigation customizers, the ability to override SharePoint navigation nodes with SPFx components, are also planned for 1.25. Both will matter for organizations building rich AI-powered interfaces, since React 18’s concurrent rendering capabilities make streaming and real-time response patterns from the Copilot APIs significantly more practical.

Installation and basic usage of the SPFx CLI

Before you run the install, note the Node requirement is >=22.14.0 <23.0.0 or >=24.12.0 <25.0.0. If your development environment is still on Node 18 or 20 which many SPFx shops are, because that is what the Yeoman path has supported, you will need to upgrade first. This is the most significant practical barrier to adoption right now. If your team runs managed developer machines, this is the conversation to have with your infrastructure team before SPFx 1.25 ships and the Yeoman path is phased out.

You can install the next-generation CLI and begin scaffolding using the standard Node package managers:

• npm install -g @microsoft/spfx-cli
• spfx create — template webpart-react — library-name “your-library-name” — component-name “Hello World”

When scaffolding a React web part with spfx create, that downloads the webpart-react template from the default GitHub source, scaffolds the project into a hello-world subfolder, and configures everything against SPFx 1.22 as of the time of writing. So those are the three required inputs (template, library name, and component name) and there is no interactive questionnaire.

Run spfx list-templates first to see the full set of available templates. Which is a much cleaner discovery experience than Yeoman provided.

The — spfx-version flag resolves to the corresponding version /<VERSION> branch in the template repository. — spfx-version 1.22 gives you the 1.22 templates. — spfx-version 1.23-rc.0 provides the release candidate templates the same day they are pushed. That was simply not possible before without waiting for a new generator publish. For development teams that need to track preview features, particularly the upcoming AI-focused capabilities planned for 1.24, this flag changes the entire early-adoption workflow.

Enterprise Template Strategy

Centralizing custom solution templates to bake governance, corporate design systems, and Copilot API patterns into new SPFx project from day one.

The CLI now supports pointing to a local directory or a custom GitHub fork to leverage your own custom templates. Native support for custom template sources within the CLI represents a significant advancement for organizations that have standardized their SPFx development processes.

If your development team has built internal SharePoint Framework patterns, you can standardize, enforce quality, and reduce redundancy across the organization by packaging these as custom solution templates and hosting them in a private or public GitHub repository. This can include such patterns as a web part scaffold pre-wired with your company’s design system and logging framework, or an extension template that already includes your error boundary, or an ACE that imports your internal data services and Work IQ client configuration.

Prior to the SPFx CLI, you have had two realistic options until now:

• Fork the Yeoman generator, which is difficult to maintain and impossible to keep current with Microsoft’s releases.
• Or document the post-scaffold steps that everyone is supposed to follow after running the generator, which in practice nobody follows consistently.

Neither option is good, and both lead to the same outcome: inconsistent projects, technical debt baked into the starting structure, and developers spending time on boilerplate instead of business logic. With the new CLI, you publish your templates to any GitHub repository and point developers at it with — remote-source:

• spfx create — template webpart-react — library-name my-project — component-name my-project — remote-source https://github.com/your-org/spfx-templates

Your custom templates are available alongside the default Microsoft source. Developers can choose from both. You can set the remote source as a persistent environment variable so no one has to pass the flag manually. For organizations on GitHub Enterprise Server, a GITHUB_TOKEN environment variable handles authentication for private repositories. For offline or air-gapped environments, — local-source points the CLI at a local folder on disk with no network access required.

The CLI also includes @microsoft/spfx-template-api, a programmatic API for template rendering that powers the CLI itself. SharePoint development shops looking for deeper integration can build on it directly. Building directly on the @microsoft/spfx-template-api unlocks complete control over your enterprise development lifecycle. By shifting from a CLI-driven workflow to an API-driven implementation, you can fully automate governance and seamlessly integrate SharePoint scaffolding into your existing developer tooling. Such as embedding scaffolding into an internal developer portal, wiring template generation into a build pipeline, or creating a VS Code extension that scaffolds SPFx components with organization-specific defaults.

Internal templates

Company-specific templates are hosted in a secure GitHub remote source, fetched by the SPFx CLI, and delivered directly to the developer’s machine as a ready-to-develop project pre-configured with internal Copilot API patterns and corporate design standards.

If your organization is building or planning to build solutions that call the Copilot APIs, your internal templates should encode those patterns from day one. Specifically:

1. Pre-wired service scope registration for singleton chat services, so AI state management is consistent across web parts on the same page.
2. The Files.Read.All and Sites.Read.All permissions declared in package-solution.json, so authorization is handled at deployment time rather than discovered at runtime.
3. The MSGraphClientV3 configuration for Work IQ authentication, using the On-Behalf-Of flow that passes the signed-in user’s identity to Microsoft Graph.
4. Placeholder integration points for Copilot and Graph API endpoints, so developers are oriented toward the right surfaces from the first file they open.

Developers who scaffold a new project from these templates start with the pattern in place rather than wiring it up from scratch.

Available SPFx CLI templates

The current default template set covers everything the old generator supported, organized into four categories. All default to SPFx 1.22. Use — spfx-version to target a different release branch.

Web Parts

• webpart-minimal → bare-bones, no UI framework
• webpart-noframework → full web part scaffold, no UI framework
• webpart-react → React with Fluent UI, the recommended starting point for most new web parts

Extensions

• Application Customizer
• Field Customizer in minimal, no-framework, and React variants
• Form Customizer in no-framework and React variants
• List View Command Set
• Search Query Modifier

Adaptive Card Extensions

• Data Visualization
• Generic
• Generic Image
• Generic Primary Text
• Search card templates for the Viva Connections dashboard

Library

• The shared SPFx library component template, for reusable packages of code
• Types
• Services
• Utilities that multiple web parts, extensions, and ACEs in the same tenant can depend on without duplicating code.

As of version 1.23 (released May 2026), this template set becomes open to community contributions. Expect templates targeting Copilot API patterns, Work IQ client setup, and Retrieval API integration to appear as those development patterns mature.

SPFx and the Microsoft 365 Copilot APIs

The Microsoft 365 AI layer, where enterprise data grounds the Copilot APIs to power intelligent experiences in SharePoint and beyond.

The reason template quality matters this much right now is that SPFx is becoming the primary development layer for Copilot-powered experiences in Microsoft 365. Understanding this connection is what makes the CLI transition more than a toolchain housekeeping exercise.

Microsoft refers to the intelligent layer of Microsoft 365 as Work IQ, the set of APIs that expose Copilot capabilities to custom applications and agents. These are accessible as standard REST APIs under the Microsoft Graph namespace (currently under graph.microsoft.com/beta/copilot, with v1.0 endpoints expected as the APIs mature), use the same authentication and authorization model as other Graph APIs, and respect your organization’s existing policies:

1. Identity access
2. Conditional access
3. Sensitivity labels
4. Permission trimming

TechNote: while Microsoft Graph APIs are available under standard Microsoft 365 license terms, the Copilot APIs require a Microsoft 365 Copilot license.

The architecture Microsoft has described places enterprise data at the foundation, the Copilot APIs in the middle handling secure grounding, governance, compliance, and responsible AI, and at the top three kinds of experiences: Microsoft 365 Copilot itself, agents built with Copilot Studio, and custom generative AI solutions. SPFx sits squarely in that third category.

Adaptive Card Extensions, the SPFx component type for Viva Connections, are the primary vehicle for embedding AI-driven experiences into the employee-facing layer of Microsoft 365. As Microsoft expands what Copilot can do on that surface, ACEs become increasingly central to the developer story.

The three Copilot APIs that matter most for SPFx developers right now form the core of the Microsoft 365 Copilot developer extensibility ecosystem.

These Copilot RESTful API endpoints allow you to securely tap into Microsoft’s underlying Work IQ engine to build custom agents, automate workflows, or embed AI directly into external apps.

The three primary pillars of the Microsoft 365 Copilot developer ecosystem for building context-aware applications.

🔍 The Microsoft 365 Copilot Retrieval API lets you pull relevant text chunks from SharePoint, OneDrive, and Copilot connectors directly into your own AI pipeline. It acts as an out-of-the-box data retriever for Retrieval-Augmented Generation (RAG). You send a prompt, and it pulls the most contextually relevant text chunks without requiring you to manage a custom vector database. There is no need to export the data, rebuild your index, or duplicate or move anything. The API queries data sources directly using the caller’s Microsoft Entra ID token, ensuring users never see information they do not have explicit permissions to access. It uses the same semantic index that powers Microsoft 365 Copilot and respects all existing permissions and sensitivity labels. It returns the grounded context chunks your application can pass to any language model.

📂 The Microsoft 365 Copilot Search API acts as an AI-powered universal file locator. The Search API performs hybrid search using natural language queries to generate highly relevant file listings, which is semantic (meaning and context) and lexical (exact wording) together, and does so across OneDrive content. It returns documents with full metadata, author information, and keyword-highlighted previews. It yields a list of matching actual files, links, and documents rather than raw text segments. Traditional search relies on exact keyword matching, but this API processes natural language questions to understand what file a user actually needs.

TechNote: In its initial preview, Search API is scoped to locate files and folders across OneDrive for work or school accounts.

💬 The Microsoft 365 Copilot Chat API delivers a complete conversational Copilot experience, connected to Microsoft 365 data, and can be embedded into any app, including an SPFx web part on a SharePoint page. It brings smart, intuitive conversations right into your custom apps, and handles multi-turn dialogue while keeping track of history and context. Unlike the other two, this API responds with fully synthesized, human-like answers complete with corporate source citations. It does so by combining enterprise search grounding with global web search grounding by default, though it does not execute action skills like sending emails or generating graphics.

The react-copilot-apis Sample

Microsoft’s Paolo Pialorsi published the react-copilot-apis sample to the PnP web parts repository in December 2025. It is an SPFx 1.22 solution built on Node 22, React, and Fluent UI, and it is the clearest demonstration available of what SPFx development looks like when pointed at the Copilot API layer.

The solution calls the Microsoft Graph Copilot APIs through the SPFx MSGraphClientV3 service, which handles Work IQ authentication and passes the signed-in user’s identity to Microsoft Graph using On-Behalf-Of. This is important: the Copilot APIs do not elevate permissions. Every response from the Retrieval API, the Search API, and the Chat API is permission-trimmed to what the signed-in user can already access. The grounding stays inside the Microsoft 365 trust boundary.

The CopilotChat web part creates a conversation with POST /beta/copilot/conversations, then exchanges messages through POST /beta/copilot/conversations/{id}/chat. Each message request can include additional context instructions that guide how Copilot responds, external file references for Copilot to consider, and a toggle to enable or disable public web content in responses. The response comes back as structured text that the web part renders as Markdown. Conversation history persists within the session. The result is a conversational Copilot interface embedded directly in a SharePoint page, scoped to the organization’s own data, with none of the infrastructure overhead of building a custom RAG pipeline.

The CopilotSearch web part calls POST /beta/copilot/search with a natural language query and returns document results with titles, authors, preview text with keyword highlighting, and direct links; semantic and lexical search combined across OneDrive, with no separate search index to maintain. The page size is configurable in the property pane.

Both web parts register their services as singletons in the SPFx service scope, which is the correct pattern for efficient Work IQ client management across multiple web parts on the same page. The permissions required, Files.Read.All and Sites.Read.All, are declared in package-solution.json and requested at deployment time through the SharePoint API permission request flow. Admin consent is required once; after that, any user with a Microsoft 365 Copilot license can use the web parts.

This is beta territory. The /beta/copilot/endpoints carry Microsoft’s standard warning that beta APIs may change. But the pattern is real, the sample is published and functional, and the trajectory is clear. The organizations that already understand the service scope pattern, the permission model, and the authentication flow will be positioned to adopt the stable v1.0 version as soon as it ships. This is precisely the pattern your internal CLI templates should encode from day one so every developer who scaffolds a new project starts with the permission scopes, service scope registration, and Graph client configuration already in place.

AI-assisted SPFx development

The ‘Work IQ’ layer sits between your organization’s secure data and the custom agents built on the SharePoint Framework.

Beyond surfacing AI to end users, developer tooling itself has become AI-first. Software engineers now rely heavily on GitHub Copilot within VS Code to accelerate the development lifecycle: handling initial React component scaffolding, generating complex TypeScript, writing unit tests, and accelerating error debugging.

The official SPFx Toolkit for Visual Studio Code extends this further with deep AI integrations that allow developers to use natural language prompts to scaffold new projects, configure local workspaces, and automate management and provisioning of SharePoint Online resources. This is where the scaffolding conversation and the AI conversation converge: the templates that get scaffolded today determine the baseline assumptions of the components built tomorrow. Outdated templates leave development teams behind in readiness to build on the Copilot APIs that are maturing right now.

SPFx CLI Production Readiness

Three things to be clear-eyed about before you move forward.

The CLI is still pre-release.

Version 0.1.0-pre.3 — Microsoft’s own documentation carries an explicit caution: for production environments, use the SPFx version referenced on the standard setup page, which still points to the Yeoman path. APIs and commands may change before the stable 1.0 release scheduled for September 2026. The right use of this tool right now is new projects, proofs of concept, and building and testing the internal template libraries you want ready when 1.0 ships.

The Node version requirement is a real gate.

Node 22 or 24 only. If your organization standardizes on Node 18 — LTS, widely used in SPFx environments because that is what the Yeoman path has required — you will need a version manager like nvm or a parallel environment to test the new CLI. In organizations with managed developer machines and locked runtimes, this is a process conversation, and September 2026 is closer than it sounds.

Templates are fetched at runtime from GitHub.

In standard environments this is fine and it is the feature you are paying for. In air-gapped networks, federal cloud environments, or enterprises with strict egress filtering, the runtime GitHub fetch is a deployment consideration. The — local-source flag handles it. Download the templates once into an internal registry or a local path, and every developer points there instead of GitHub. Include this in your environment planning alongside the Node upgrade.

Summary

As SharePoint matures into the enterprise knowledge hub for Microsoft AI, the transition to the SPFx CLI is the critical final step in aligning your development toolchain with the three-tier architecture of Microsoft 365 Copilot. Ensuring your custom components are grounded, governed, and ready for the AI layer.

I have been through every major toolchain transition in SharePoint. From full-trust farm solutions (.WSP) to the SharePoint add-in model, from the add-in model to SPFx, from Gulp to the Heft build system that shipped with SPFx 1.22. Each transition had a friction period, and the organizations that prepared early came out ahead. This one is no different, except the stakes are higher. This transition is about positioning your development team to build the next generation of AI-powered SPFx solutions.

The new CLI is the right design. Decoupling the tool from the templates was overdue. The open-source model, community template support, and programmatic API all reflect a more mature understanding of how enterprise development teams actually work. The CLI goes to GA in September 2026 at the same moment that AI extensibility capabilities are landing in SPFx 1.24 and 1.25 and the Copilot APIs are maturing from beta toward v1.0 stability. The scaffolding modernization and the AI extensibility investment are moving together because they have to. The next generation of SPFx templates will need to know about Work IQ, the Microsoft Graph Copilot endpoints, the service scope patterns for AI clients, and the permission scopes required for grounded retrieval. You cannot ship those templates through the old generator model.

My practical advice:

• Upgrade your Node environment now.
• Install the pre-release CLI and run it against a non-production project this month.
• Start designing what your organization’s internal template library should look like — particularly if you are planning to build solutions that call the Copilot APIs.

The templates you author in the next three months are the ones your team will be scaffolding from in Q4. The organizations that do this work in advance will not feel the September transition at all. The ones that wait will spend October doing what they could have done in June.

The Yeoman generator did its job for nearly a decade. It is not broken. But the new CLI is what SPFx scaffolding should have looked like from the start, and Work IQ is what SPFx development is going to look like from here forward. Understanding both together is the edge.

Watch the SharePoint/spfx repository and the npm package page for the 1.0 milestone. That is when this becomes the default path for everyone.

About the author: Sousouni Bajis is a Microsoft consultant and SharePoint subject-matter expert with more than twenty years of experience delivering enterprise-scale SharePoint, Power Platform, and Azure solutions for Fortune 100–500 organizations and regulated government environments. He writes the Mastering Microsoft 365 and Beyond blog at sousounibajis.com and advises organizations on SharePoint strategy, governance, and AI readiness through Yoppa Tech Solutions.