Microsoft recently released a survey seeking input on the SharePoint Framework (SPFx) developer experience. You can submit your thoughts here: aka.ms/spfx/devtools/feedback.
Initially, the survey focused on opinions about dropping Gulp from SPFx projects, presumably in favor of relying entirely on npm scripts and webpack. After receiving feedback, they broadened the scope to include any other input.
Over the years, I’ve provided Microsoft with extensive feedback on the SPFx developer experience and tooling. Rather than repeating my usual comments, I decided to share my true feelings.
That is: I’d like to see a complete reimagining of the SPFx developer tooling.
Let me elaborate on what I mean.
A Fundamental flaw in SPFx tooling
When Microsoft created the SPFx developer tooling, they incorporated numerous dependencies from both internal and external packages. This included packages from other Microsoft engineering teams to handle compilation and other build tasks in a Node.js-based project.
Unfortunately, this extensive dependency tree introduced significant rigidity. It made it challenging for both the SPFx team and developers to use the latest tooling in the core SPFx build process. Moreover, it hindered anyone wanting to integrate third-party tools such as testing and mocking libraries.
But returning to the survey—in my view, the core issue isn’t the dependencies Microsoft chose for the SPFx project creation and toolchain, including the use of Gulp.
The real problem lies in this inflexibility.
In my recap of the most recent SPFx v1.20 release, I highlighted—or more honestly, ranted about—the fact that we’re stuck with very old versions of React, TypeScript, and other libraries.
What I’d like to see Microsoft do isn’t just remove specific dependencies. Instead, they should take a step back and open up the toolchain, giving developers much more freedom and flexibility in what they want to use. At the same time, they should provide a first-run experience for developers who prefer a process similar to what we have now—those who don’t want to customize and just want the same out-of-the-box experience we essentially have today with the Yeoman based SPFx generator.
Proposal - A new SPFx project generator
I believe we can satisfy the needs of Microsoft, developers who prefer the existing experience, and those who want more control. My proposal is an engine that functions similarly to the current one: when creating a new project, you answer a few questions, and the tooling generates the directory and file structure for your project.
However, instead of solely relying on the project structure in the SPFx generator, this engine would also support pulling project structures from remote repositories.
This approach would allow developers to maintain their current experience while giving Microsoft control over the default templates. Additionally, developers could create and store their own project templates in their repositories. The same tool could then be used to access Microsoft’s project templates, custom templates, or community-sourced templates.
To better illustrate how this would work from a user’s perspective, let me walk you through a few scenarios.
Example 1 - Custom project templates
Using the zero-install npx CLI, developers can create a new React-based web part project with the following command:
npx spfx new project
Welcome to the Microsoft 365 SharePoint Framework Yeoman [email protected]!
Let's create a new SPFx solution...
? What is your solution name? HelloWorldSolution
? Which type of client-side component to create? WebPart
? What is your Web part name? HelloWorld
? Which template would you like to use? React
... creating your project...
... project creation complete!
Execute `code .` to launch the project in VS Code.
The only requirement for developers would be a modern version of Node.js. The npx CLI would execute the utility, prompting users with questions about their project. This example would use the same prompts as the current Yeoman generator. It would also leverage a project template defined within the default engine, ensuring developers have the same experience they have today.
But there’s one significant difference: developers wouldn’t need to install Yeoman or the Yeoman generator.
You’d still need to install the Gulp CLI globally, as that’s what SPFx currently requires.
Now, consider the possibilities for custom solutions that organizations and community developers could create.
Here are some examples:
Example 2 - A SPFx web part project that only uses React and NPM scripts
Gulp is merely a task runner. We could implement all the same functionality we currently use Gulp for with custom npm scripts and webpack plugins.
npx spfx new project my-spfx-react-npm
Welcome to the Microsoft 365 SharePoint Framework Yeoman [email protected]!
Let's create a new SPFx solution...
? What is your solution name? HelloWorldSolution
? Which type of client-side component to create? WebPart
? What is your Web part name? HelloWorld
? Which template would you like to use? React
... creating your project...
... project creation complete!
Execute `code .` to launch the project in VS Code.
In this example, I could create a template that uses npm scripts and webpack plugins along with a custom project template stored in one of my repositories.
But notice how this looks almost identical to the first example—except for the end of the first line: my-spfx-react-npm?
That would reference a configuration on my machine:
{
"my-spfx-react-npm": {
"prompts": [
{ "name": "SolutionName", "prompt": "What is your solution name?" },
{
"name": "ComponentType",
"prompt": "Which type of client-side component to create?",
"choices": ["WebPart", "Extension", "Library", "ACE"]
},
...
],
"templates": [
{
"responses": {
"ComponentType": "WebPart",
...
},
"project-template": "andrewconnell/spfx-proj/tree/main/my-spfx-react-npm"
}
]
}
}
This is just a partial idea for a configuration, but you get the picture. You define the prompts and map the responses to a specific template in one of my GitHub repos. The engine would then clone the repo and the appropriate folder within it, performing string replacements based on the responses to other prompts.
You can see how this would give us a lot of control over our own project templates. In fact, you could create even more options, such as…
Example 3 - SPFx with Vite
In this example, I could create a project template that uses Vite to handle the entire build and test process of an SPFx project from a template that I create in my own repository.
Example 4 - Create an SPFx project for a react, web part complete with Jest tests
This example showcases how I could create a custom project template that comes pre-configured with all the necessary components for implementing unit tests using Jest.
Example 5 - SPFx projects that include third-party libraries
Many SPFx developers rely on the popular PnPjs library for accessing data from Microsoft Graph and SharePoint Online in their projects. In this example, I could create a template that incorporates both the PnPjs package and the H2O UI library—a community-driven UI library based on Microsoft’s Fluent UI design language:
npx spfx new project my-spfx-react-npm
Welcome to the Microsoft 365 SharePoint Framework Yeoman [email protected]!
Let's create a new SPFx solution...
? What is your solution name? HelloWorldSolution
? Which type of client-side component to create? WebPart
? What is your Web part name? HelloWorld
? Which template would you like to use? React
? Add popular libraries?
[x] PnPJs
[x] hTWOo
[ ] SPFx Fast Serve
... creating your project...
... project creation complete!
Execute `code .` to launch the project in VS Code.
Next steps
I believe a tool like this could significantly expand opportunities for developers creating SPFx projects. Microsoft could maintain their own project templates while empowering organizations to create their own standardized templates. This approach could even foster the community’s development of a diverse library of project templates.
But why stop there?
Why should this concept be limited to the SharePoint Framework?
This versatile project template structure could extend beyond SPFx projects, encompassing generic Microsoft 365 projects, Microsoft Teams projects, Copilot extensibility, and more. The possibilities are truly boundless.
I’m curious, though—what do you think? If such a tool existed, would you embrace it?
Would you be inclined to create project templates if the process was straightforward?
Share your thoughts in the comments below. What project templates do you envision using or commonly setting up for your clients?