A few months ago I created a tool, which speeds up a regular "gulp serve" process. In a nutshell, it uses a separate webpack based build. Please read this post to learn more. Since the initial release, I've fixed a few good things and added new features. The most awaited is library components support. Read further to find out how to use spfx-fast-serve with library components. 

You can manage library components in two different ways: with a special multi-package manager (Lerna.js) or without. Lerna is not the only multi-package manager, there is also Rush.js, however I know Lerna, I wrote a blog post on how to use Lerna with library components before, Lerna is simple and has least issues when working with SharePoint Framework. More...

In August 2019 SharePoint Framework 1.9.x was released. Among different changes also support for Webpack 4 was introduced. What does it mean for us? It means slightly improved build speed, support for a wide range of plugins and better tree-shaking. 

What is webpack tree-shaking exactly? In simple words, webpack is smart enough to automatically remove "dead modules" (in other words unused code/modules) from your resulting bundle. It reduces the size of the resulting bundle, thus improves load performance. More...

A few months ago I wrote an article about SharePoint Framework build performance - SPFx overclockers or how to significantly improve your SharePoint Framework build performance. I've tried to reduce the amount of time the "gulp serve" command uses to re-build your code and to finally refresh a browser. I used different optimization technics for that purpose. The idea was to tweak the default SPFx build pipeline. However, those post only partially solves the problem. 

In this post, I will solve the problem from another way around (spoiler: I managed to make "serve" 10-15 times faster). 

The idea

How SharePoint Framework's "gulp serve" works? It gets your sources and outputs javascript bundles. But "gulp serve" becomes slow when your solution grows. How to fix that issue? Well, since it's slow, then don't use it! 

So this is the idea - don't use "gulp serve", use a completely custom webpack based build to transform your sources into exactly the same javascript bundles which are produced by "gulp serve". 

What is the input for "gulp serve"? - TypeScript sources, styles. What is the output? - Javascript files. Can we get sources and produce exactly the same javascript? -Yes.

How it works

Some nerdy content goes below. If you don't want to read about internal implementation, go directly to "How can I use it?". 

Also please note, that the internal implementation was changed since this post was written, however the main idea is still the same.

To make it work, we need a custom webpack config and webpack dev server to serve webpack output. More...