You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Review Vite integration test to ensure each entry is built independently. If this means having two separate scripts that each build an entry, that's fine.
Why
Vite seems to treat the two entries we configured for building as part of a single thing, and extracts shared code in its own module. This would make sense if we were building a single project with multiple entry points. However, what we want to do is check that each of our entry points, when build on its own, includes what we expect. Because Vite splits the shared code in its own file, we can't verify that tree-shaking works by only looking in the build initAll.mjs or single-component.mjs, as some code in the shared module may not have been tree-shaken, or may be there because initAll imports it.
Who needs to work on this
Developers
Who needs to review this
Developers
Done when
Vite builds the two entries independently
The text was updated successfully, but these errors were encountered:
Digging further, Rollup (which is what Vite uses during the build), automatically creates chunks (separate files imported by the "main" bundle) when it notices shared code across entries. This leads to a button-[hash].js file to be created with the code for the Button and its depedencies, that is then imported by the built initAll.js and single-component.js. To properly validate that tree-shaking works, we'd want that code bundled with initAll.js and single-component.js so that:
we have only one place to look into and don't miss that a component gets mistakenly included in the shared chunk without us noticing
results are not skewed by what Rollup deems shared by the two modules, which is ultimately the responsibility of the consumer code.
Library mode
Vite offers a Library mode, which defines the entries outside of the build.rollupOptions. Unfortunately, it doesn't change the behaviour regarding code splitting, and a shared button-[hash].js file ends up being created as well.
Rollup's manualChunks option
Rollup offers a manualChunks option to create custom chunks. Unfortunately, it only creates new chunks and doesn't disable the automatic creationg of chunks for shared code amongst entries. Indeed, neither undefined or {} prevented the creation of the chunk.
Further investigation led to discovering that disallowing automatic creation of chunks is not something that Rollup supports. And because it's wrapped inside Vite, we do not have the option of providing an array of RollupConfiguration to make build each entry independently, as we do for the build of govuk-frontend
This behaviour is unfortunately not controlled by the looks like Rollup doesn't allow todisable the automatic creation of chunks , which is a shame. Because it's wrapped inside Vite, we do not have the option of providing an array of RollupConfiguration to build each entry independently.
If it's Rollup under the hood, do we need to look at Vite
Easiest is to have separate config files, as well as scripts (because vite cleans the output directory) and entry in the GitHub action matrix for each entry we want to build. For this, I've opened #4981.
What
Review Vite integration test to ensure each entry is built independently. If this means having two separate scripts that each build an entry, that's fine.
Why
Vite seems to treat the two entries we configured for building as part of a single thing, and extracts shared code in its own module. This would make sense if we were building a single project with multiple entry points. However, what we want to do is check that each of our entry points, when build on its own, includes what we expect. Because Vite splits the shared code in its own file, we can't verify that tree-shaking works by only looking in the build
initAll.mjs
orsingle-component.mjs
, as some code in the shared module may not have been tree-shaken, or may be there becauseinitAll
imports it.Who needs to work on this
Developers
Who needs to review this
Developers
Done when
The text was updated successfully, but these errors were encountered: