Install Spfx Fast Serve
Matilda Equiluz
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
I started developing SharePoint Framework solutions back in 2018. And like many other developers, I was always frustrated by how slow the development process felt. For example, you would add a line of code and then wait for up to five minutes before you could see the changes you had made. I would use this time to grab a fresh cup of coffee or check my mailbox. Needless to say, by the time the "gulp serve" task was done, I was too distracted doing something completely unrelated. As a result, a minor change could take hours.
Despite some performance improvements over the last few years, it is still not fast enough to enjoy the SharePoint Framework (SPFx). That is unless you are already using spfx-fast-serve. After spending a few moments to set it up, all my SharePoint Framework projects are now serving up to twenty times faster! I am blown away by how fast I can now develop using SPFx.
The local workbench is deprecated in SPFx 1.13. The corresponding features were also removed from spfx-fast-serve. As a result, serve setting "open" was removed. Originally the setting meant "open local workbench". Now if you wish to open any URL after the "serve", you should use "openUrl" setting instead.
In the previous version, spfx-fast-serve tried to automatically detect the ESLint usage. In SPFx 1.13 it works differently. For performance reasons by default now ESLint is disabled even if you have ESLint support in your SPFx solution. Now you have to explicitly add a new setting called "eslint" (true or false) to the "serve" options. When "eslint: true" in your spfx-fast-serve config, it will add eslint-webpack-plugin to the webpack configuration. By default it uses "lintDirtyModulesOnly: true". It means that ESLint will check only files you changed and not the whole project (otherwise it might be very slow).
This is something completely new introduced for SPFx 1.13 and onwards. SPFx 1.13 added a new type of extension called Adaptive Cards. Mostly it's used inside Viva Connection Dashboards and mobile experiences. In the hosted workbench you can test adaptive cards. But what if you want to continue local development and see how it looks like inside your Viva MS Team's mobile app? Of course, you can use mobile view in dev tools, however on the actual device, it might be different. Or what if you have a bug, which is reproducible on a mobile device only?
With spfx-fast-serve you can create a kind of proxy between your locally running dev server and Viva app, loading development javascript. You can use the ngrok tool as such a proxy and the NgrokServePlugin from spfx-fast-serve. This approach works also for Teams Tabs if you wish to test them on mobile.
You can use existing or just scaffold a brand new SPFx project with an adaptive card extension. Make sure to set Do you want to allow the tenant admin the choice of being able to deploy the solution to all sites immediately without running any feature deployment or adding apps in sites?: Yes.
Why webpack plugin and not a configuration setting? What if you want to run ngrok from javascript using API? In that case, the URL will be different every time (unless you use the paid account of course). What if in the future I will have to introduce additional parameters? The last argument is that I don't expect this feature will be used frequently. That's why the webpack plugin.
It is very easy to create a new SPFx project and you can find a lot of posts about it. One of these posts is, of course, the one from Microsoft. But what should you do after the "empty" project is created?
I will describe what I personally do after I create a new project. Some steps may not be relevant for you because you prefer a different way of working or structure your project differently. But maybe there's one or two things you didn't know yet and think it's good.
I have often mentioned that I like the npm package spfx-fast-serve developed by Sergei Sergeev. If you don't know it, you must use it! So the first step I do after creating the project is to run the spfx-fast-serve command in my terminal. This is of course only possible if you have installed the package globally before. After running the command, the tool prompts you to run the npm install command again. Since I switched to pnpm, of course, I have to run pnpm install
Custom aliases allow you to create (mostly) shorter and more intuitive paths for your imports. This is especially beneficial in larger projects where multiple levels of folder structures can lead to unwieldy (relative) paths. But it is also helpful if you want to reuse the modules later because then you don't have to work with the relative paths anymore. Here is the same example as above, but with the alias:
The tsconfig.json file is the configuration file for TypeScript projects and provides various options to control the behavior of the TypeScript compiler. By extending this file in your SPFx solution, you can better customize the TypeScript compilation process to suit your project structure and needs.
The baseUrl property in tsconfig.json allows you to set a base directory for module resolution. This means you can define a central starting point for your imports, reducing the need for long relative paths.
For example, by including a baseUrl property pointing to your project's src directory, you establish a foundation for cleaner, more intuitive imports. But I personally point to '.'. Here is an example of how the file tsconfig.json looks like after the change:
I always create an alias for the src folder (that's why my baseUrl points to '.' and not 'src'), the webparts folder and the components folder. But of course, you can also create your own alias. This is how the tsconfig.json looks like after the change:
After running the command spfx-fast-serve in your terminal (described above), the command added a new folder in the root of your project, called fast-serve, containing a file called webpack.extend.js. Again, we need to register the alias so webpack can resolve it.
NOTE: In webpack.extend.js you should use the src path again. And because the file is in a folder, you need to add a '..' after __dirname when calling the path.resolve method. And again, do not forget to import the path package!
If you want to have a command to increment the SPFx solution version (config/package-solution.json) and the package.json version, then you should define a custom gulp task like I do. And even more, if you want to build the solution, increase the version and package the solution with one command, then you should read my post on how to do that.
Since SPFx v.1.15 was released, Microsoft switched from TSLint to ESLint. Actually a good decision, but some rules annoy me personally. Especially if you use spfx-fast-serve and you are still developing the modules. Sometimes you just want to test something fast and define variables that are not used (yet). Or you comment out a code and the method is now "empty". Then errors are output and often the spfx-fast-serve process is stopped => you have to start it again after fixing.
It has less to do with the topic of the article, but maybe someone is interested in what my folder structure looks like, which I (almost always) create. Of course not immediately, but only when I need it.
Technically, it's the same codebase and functionality as 2.0, however recent findings made me available to drastically change the way of handling the "serve" command. Also, I removed some cli options (pnpm now is supported out-of-the-box, sp-rest-proxy is supported as an extension using webpack.extend.js). Since cli options were changed and the "serve" handling, I had to introduce a new major version.
Check out this doc to learn how to upgrade to the latest 3.x version. If you use spfx-fast-serve, I recommend you migrate to the 3.x version today, because all future updates will be based on the 3.x version only. This version is considered stable and no more major releases planned in the nearest future.
At the very beginning, this tool was more like an experiment to see what is possible and also to see the potential limitations. During last year I fixed a bunch of bugs, added support for library components. However, the code was not as good as it should be. It was just a javascript file with all the logic. I see that the usage of spfx-fast-serve is growing, thus decided that it's a good chance to make it better.
In a new version, everything is done using TypeScript with a lot better architecture. Different commands are responsible for different solution modifications - package.json update, gulpfile update, write webpack.js to disk, etc. It will be a lot easier to maintain and to upgrade between different SPFx versions. It also easier for potential contributors to make changes.
A common request for spfx-fast-serve was "how to prevent it to open a browser" or "how to change webpack configuration so that it..." etc. Some solutions also extend default SPFx webpack configuration, so they had to modify webpack.js accordingly. This is inconvenient, because next time you run $ spfx-fast-serve for an update, your webpack.js will be overwritten.
spfx-fast-serve 2.0 introduced a new extensibility model. Now it adds a file called webpack.extend.js (by the way, all files are currently under a separate folder called fast-serve). It's supposed that you put all of your solution-related webpack modifications into this file.
If it's not enough and you cannot use "merge" mechanism, then you can use transformConfig function. It works the same as SPFx's "mergeConfig.additionalConfiguration" - it accepts the base config as a parameter, then in a function body you can do whatever you need and return back the updated config.
The cli contains parameters you used last time when running spfx-fast-serve. It means that on the subsequent runs you don't have to supply the same set of parameters. If you use another parameter in a command line, your config.json will be overwritten. This file is important because webpack.js relies on configuration values from this file.
4a15465005