[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:
Relates
relates to STCLI-154 Add support for creating and consumin... Closed
relates to STCOR-428 investigate webpack dll plugin Closed
relates to STCOR-471 Add support for React Webpack DLL bundle Closed
relates to STCOR-474 Add support for creating and consumin... Closed
relates to STCOR-475 Add support for creating and consumin... Closed
relates to UXPROD-2767 R1 2021 | Stripes-force Tech debt Closed
relates to FOLIO-2672 SPIKE: figure out how to workaround r... Closed
relates to FOLIO-2889 Documentation: stripes bundle pre-com... Closed
relates to STCOR-487 Build with Webpack DLL without needin... Closed
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 STCLI-154 Closed and STCOR-471 Closed to this Sprint (aka Sprint 100)?

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 STCLI-154 Closed and STCOR-471 Closed to this Sprint (aka Sprint 100).

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
https://github.com/folio-org/stripes-vendor-dll

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.

Generated at Thu Feb 08 23:22:24 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.