Long build times for SPFx projects with many components

[vman]

Category

• [x] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When developing/testing using gulp serve for large SPFx projects (more than 25 webparts and extensions), only the changed files should be built using webpack.

Observed Behavior

For large SPFx projects (including the SharePoint starter kit) where there are a large number of components, with every code change it takes about 25 seconds for webpack to build the new bundle.

This means even if we modify a single line of code, we have to wait for webpack to build the entire bundle with all the components.

I have seen this issue is mainly because SPFx adds each component by default as a separate bundle: https://github.com/SharePoint/sp-starter-kit/blob/master/solution/config/config.json

If I move all components to a single bundle, the build time is reduced considerably. But then we have the issue of having all components in a single bundle and code might be loaded on the page even if it's not needed.

Steps to Reproduce

1) Clone the SP Starter Kit repo 2) npm install 3) gulp serve 4) Observe that it takes about 25 secs for webpack to build the bundle 5) Change a line of code in any webpart and save 6) Observe that again it takes about 25 secs for webpack to build the bundle

[StfBauer]

Sometimes not only many components are required to slow down the build performance. I already mentioned in #2885 I also did some further observations and there are three critical components causing the performance drain:

• TypeScript compiler
• TSLint
• WebPack

It also seems like that everytime a new build runs the whole gulp build rig get initialised like you would start gulp serve fresh. Instead of having a persistent base configuration and adapt to changes in the source code.

[effectivetom]

Has anyone experimented with fork-ts-checker-webpack-plugin, thread-loader or other third party tools?

I've seen them improve the performance of other webpack based projects but don't have the required expertise to integrate them with an SPFx project.

[ravinleague]

Is there an update on this issue ?

[vman]

@ravinleague I am expecting webpack 4 which is part of the next SPFx version (1.9.1) should help in speeding up the build times. The next SPFx version should be out in early august as mentioned in a recent PnP call.

[campuslane]

I have this same problem with extremely long build times (even for the simple SPFX Hello World webpart with no modifications). I just tried the recently released 1.9.1 version and it didn't seem to improve the performance. It still takes a really long time, and makes SPFX web part development inefficient and a real pain.

[alirobe]

Try this:

build.configureWebpack.mergeConfig({
    additionalConfiguration: generatedConfiguration => {
        if (generatedConfiguration.optimization) {
            generatedConfiguration.optimization.minimizer[0].options.parallel = true;
        }
        return generatedConfiguration;
    }
})

In the gulpfile for your project. (Tested on 1.9.1 / webpack 4). It'll at least paralellize the problem. The current config just maxes out a single core...

[aronbardsley]

Hi All,

I'm also having issues with this. I would expect gulp serve to do incremental compilation on changed ts files only - instead of re-compiling/packaging the entire project each time. This would at least speed up the development process (I don't mind waiting minutes for a release build, but not for dev...)

[ravinleague]

Apparently, I believe the new spfx version should fix the long build times issues, however, this comes down to webpack.

On Wed, 18 Sep 2019 at 3:06 pm, aronbardsley notifications@github.com wrote:

Hi All,

I'm also having issues with this. I would expect gulp serve to do incremental compilation on changed ts files only - instead of re-compiling/packaging the entire project each time. This would at least speed up the development process (I don't mind waiting minutes for a release build, but not for dev...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SharePoint/sp-dev-docs/issues/3355?email_source=notifications&email_token=AEO5R7CBNHBXWFLV4Y4R4B3QKGZOBA5CNFSM4GTH2UBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66ZZXI#issuecomment-532520157, or mute the thread https://github.com/notifications/unsubscribe-auth/AEO5R7APMRWUHTEJHTBKGHTQKGZOBANCNFSM4GTH2UBA .

-- Regards, Ravi Challa

[s-KaiNet]

You can try to apply some hints to improve the performance of serve from my article here.

[nayots]

We have a big project, that builds 3+ minutes on a powerful machine (16gb of ram etc.). The build times for SPFX are absolutely ridiculous . The lack of hot reloading also is something that should be addressed.

[pdemro]

I tinkered with the long build times this morning for debug purposes of a single webpart and was able to reduce webpack build time by around 96% by removing everything except @microsoft components from package.json (5 minutes down to 18 seconds). This "fix" works for debugging a single webpart scenario

I suspect this has something to do with the WriteManifestsTask (\node_modules\@microsoft\sp-build-core-tasks\lib) since this is the only thing I can find which parses package.json.

[jpalo]

Sometimes it takes few seconds, but after working with the project a while, this is the result.

[11:40:45] Starting subtask 'webpack'...
[11:41:28] Finished subtask 'webpack' after 43 s
[11:41:28] Starting subtask 'configure-webpack-external-bundling'...
[11:41:28] Finished subtask 'configure-webpack-external-bundling' after 752 μs
[11:41:28] Starting subtask 'copy-assets'...
[11:43:13] Finished subtask 'copy-assets' after 1.75 min
[11:43:13] Starting subtask 'write-manifests'...
[11:43:16] Finished subtask 'write-manifests' after 3.33 s
[11:43:16] Starting subtask 'reload'...
[11:43:16] Finished subtask 'reload' after 1.22 ms

[lianjim]

The build time is really ridiculous and frustrating, most of my time is spent on waiting for the changes to be applied during development. No hot loading as well. For next project, I'll pursue customers to use back classic SharePoint + js instead or i'm charging double effort to them.

[makafsal]

Why this much time takes with an 8gb and Core i5 8th gen system.

[17:50:38] Finished subtask 'webpack' after 5.48 min

[s-KaiNet]

Hello there again.
As an alternative, you can try the approach suggested here - spfx-fast-serve. In a nutshell, it creates a separate fast webpack based build, which produces the same javascript output, as SPFx does.

[pdemro]

After doing the initial NPM install, clear out everything in your package.json. From what I remember when I was looking into this, the SpFx gulp build/serve process does a long running operation on these files on every build for some reason

[stact]

I am reassured to know that this is not my environment.

Stuck on webpack

gulp bundle --ship [12:51:17] Starting subtask 'webpack'...

Current time

Trying to recompile pnp-search parts

[stact]

Ok running on node for WSL 2 is still stuck after 1hour.

Running on node for Windows (.msi) working after 35 seconds

[patmill]

Closing as a dupe of # 2885, and the comments from there apply here as well. We will take build speed into consideration as we make improvements to the tooling, and looking at the spfx-fast-serve may help here in the meantime.

[ghost]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues