This is the second part of our recent webpack updates. This PR will likely require more discussion on the pros/cons of the proposed changes, as well as some refinement since we included a couple of potential paths forward which we'll need to decide between.
In summary, this PR provides a starting point for implementing proper code splitting of our JS assets, and a way to have WP enqueue the chunk files webpack creates. Currently, we rely on a single statically-named JS asset file per webpack entrypoint. This works fine, but it has some downsides:
We have to handle cache-busting ourselves via a custom webpack plugin, instead of using the default method available via weboack (e.g. including a contenthash in the resulting filename).
Common dependencies across entrypoints end up being duplicated between the resulting built asset files, instead of being split into chunk files that can be used by more than one entrypoint. This results in a reduced ability to cache common code and unnecessarily large bundle sizes.
We may decide to discard this functionality as something provided out of the box by Groot, and instead document it as a potential update that can be added into themes which are based on Groot if/when needed.
This is the second part of our recent webpack updates. This PR will likely require more discussion on the pros/cons of the proposed changes, as well as some refinement since we included a couple of potential paths forward which we'll need to decide between.
In summary, this PR provides a starting point for implementing proper code splitting of our JS assets, and a way to have WP enqueue the chunk files webpack creates. Currently, we rely on a single statically-named JS asset file per webpack entrypoint. This works fine, but it has some downsides:
contenthashin the resulting filename).We may decide to discard this functionality as something provided out of the box by Groot, and instead document it as a potential update that can be added into themes which are based on Groot if/when needed.