[FOLIO-2673] SPIKE: investigate if stripes bundle can be "precompiled" Created: 01/Jul/20 Updated: 06/Jan/21 Resolved: 20/Oct/20 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Jakub Skoczen | Assignee: | Ryan Berger |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||
| Sprint: | stripes-force 98, stripes-force 99, stripes-force 100, stripes-force 95, stripes-force 96 | ||||||||||||||||||||||||||||||||||||||||
| Development Team: | Stripes Force | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
We are facing high mem and cpu load when compiling Stripes bundles. It would be interesting to investigate if some of the compilation work can be performed during individual module compilation so that a bundle created from (mostly) released UI modules can be compiled more efficiently. Also, are there any steps that can be skipped when constructing the bundle if the bundler is supposed to be used for development only? John Malconian jroot Stanislav Miroshnichenko please provide more details, if any |
| Comments |
| Comment by John Malconian [ 01/Jul/20 ] |
|
I wonder if, for development purposes only, Snowpack is a viable alternative. https://www.snowpack.dev/ |
| Comment by Khalilah Gambrell [ 08/Jul/20 ] |
|
per 7/8 stripes-force meeting, Ryan is assigned to this spike. Will consider for Sprint 94 or 95. |
| Comment by Ryan Berger [ 07/Oct/20 ] |
|
As I've been working on this, I started testing out Snowpack, but did find that it did not play well with a number of aspects to our bundling process such as the `stripes-config` imports. Could get there potentially with more massaging, but for the time being, I'm focusing on https://webpack.js.org/plugins/dll-plugin which would be far less invasive to our current setup but should still provide the same benefits. |
| Comment by Khalilah Gambrell [ 19/Oct/20 ] |
|
Ryan Berger, should we add
|
| Comment by Ryan Berger [ 20/Oct/20 ] |
|
Confirmed that we can pre-compile using Webpack DLL plugin. Created stories linked to this story for implementation. |
| Comment by Ryan Berger [ 20/Oct/20 ] |
|
Yes, let's add
|
| Comment by Michal Kuklis [ 06/Jan/21 ] |
|
We spent some time working on the DLL approach. The DLL which includes 3rd party dependencies (react, moment, etc) is now included in There are two way to consume it: 1. Add "@folio/stripes-vendor-dll" to package.json in the ui module / platform you want to build: "@folio/stripes-vendor-dll": "1.0.0" Then yarn it and run: stripes build ./stripes.config.js --useDll ./node_modules/@folio/stripes-vendor-dll/output/stripesVendorDll.json 2. Clone stripes-vendor-dll from https://github.com/folio-org/stripes-vendor-dll and run: cd ./stripes-vendor-dll && yarn && yarn build Then from the module or platform folder run: stripes build ./stripes.config.js --useDll ../stripes-vendor-dll/output/stripesVendorDll.json The stripes-vendor-dll currently only includes 3rd party dependencies with some stripes dependencies (stripes-components). With this setup we noticed only 20% improvement while building platform-complete. With stripes-core included in the DLL the build performance was about 10x faster. The stripes-core, stripes-smart-components, redux-form and redux-final-form are currently not included in the vendor DLL due to the way the stripes-core is structured. When trying to create a DLL with stripes-core I ran into an issue related to stripes-config. stripes-core currently consumes stripes-config so the default stripes-config is also being included in the DLL bundle. When that DLL is being used to create a fresh build with a new stripes.config.js the previous one from the DLL is being used. I tried to extract stripes-config into a separate DLL and make the vendor DLL depend on it. That way the vendor DLL could be used and just swap the stripes-config DLL with the fresh one. That didn't work out well because the stripes-config also includes getModule which pulls in code for individual ui modules which also include stripes-core. This creates a circular dependency: stripes-core -> stripes-config -> getModule (ui module) -> stripes-core. We will need to restructure stripes-core / stripes-config first before we can make any further progress with this. |
| Comment by Michal Kuklis [ 06/Jan/21 ] |
|
Another idea to explore here is to use webpack externals: https://webpack.js.org/configuration/externals/ I'm not sure yet if this plays nicely with DLL but it's worth trying it out. |