Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upPlease make long term caching better supported out of the box #4913
Comments
This comment has been minimized.
This comment has been minimized.
|
I second this. Getting long-term caching working involves a lot of trial-and-error, as evidenced by this issue. It also requires you to know too much about the internals of webpack in order to get it to work. Why should I have to know how webpack identifies modules internally in order to fingerprint my files deterministically? I think This: output: {
filename: '[name].[chunkhash].js'
},
plugins: [
// Order matters. 'vendor' must come before 'runtime'
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor'
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime'
})
]instead of this: output: {
filename: '[name].[chunkhash].js'
},
plugins: [
// Order matters. 'vendor' must come before 'runtime'
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor'
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime'
}),
new webpack.NamedModulesPlugin(),
new webpack.NamedChunksPlugin()
] |
This comment has been minimized.
This comment has been minimized.
|
All the various and extremely confusing combinations of multiple caching plugins should really be deprecated in favour of default behaviour at https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31 Moreover, this page should feature prominently in each and every page that discusses caching until caching is solved. |
This comment has been minimized.
This comment has been minimized.
|
I got most of my example config from the official docs on caching. Not sure what's "extremely confusing" about it. Although, I do agree the one from the medium article is more robust. |
This comment has been minimized.
This comment has been minimized.
|
Thta page is just a "running start". If you need an actual caching solution, you have to follow the several-screens-long explanation in the medium post. However, caching as described in the post should work out of the box, and not require umpteen plugins with arcane configurations to get what you need in the first place. On top of that, that entire documentation page is already outdated because CommonChunksPlugin is removed in webpack v4. Thankfully, persistent caching is in the roadmap for v5. |
This comment has been minimized.
This comment has been minimized.
|
Cool, I think it makes sense to point people to that article in the meantime. |
…ifest. Current use case & Webpack 3.8.1 didn't appear to need any of various plugins and techniques described: - https://webpack.js.org/plugins/hashed-module-ids-plugin - https://webpack.js.org/plugins/named-modules-plugin - NamedChunksPlugin (built-in, mentioned in predictable caching article) - https://webpack.js.org/guides/caching/#conclusion - https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31 - webpack/webpack#1315 - webpack/webpack.js.org#652 - webpack/webpack#4913 - https://gist.github.com/jouni-kantola/1c1e2bfaebf30de50d1b6a71b869da13 - https://gist.github.com/sokra/ff1b0290282bfa2c037bdb6dcca1a7aa
Do you want to request a feature or report a bug? Feature
What is the current behavior? Currently, predictable long term caching of output chunks is difficult to achieve. After reading this article, I was surprised to learn two things:
CommonsChunkPluginintegration for every project will be different. However, there are a number of concepts required for consistent long term caching which are not used by default, including the pluginsNamedChunksPlugin&NamedModulesPlugin, and ensuring that all chunks have a module identifier.The documentation for caching includes minimal explanation for using module identifiers instead of facilities for supporting long term caching:
However, for production projects, this means that more work needs to be done to ensure that long term caching is possible since the defaults do not support it, and the rapid state of change in the webpack codebase (and supporting documentation) can easily be missed by devs on webpack projects.
What is the expected behavior? It would be nice to have sensible defaults that make long term caching easier, such as including
NamedChunksPluginandNamedModulesPluginby default, and ensuring that all modules have an identifier. Additionally, in the future it would be nice to include config options that more simply expose some (pardon the pun) common use cases ofCommonsChunkPluginbehaviors, like breaking out chunks into their own files, creating a runtime chunk, and including async children chunks in a parent chunk.If this is a feature request, what is motivation or use case for changing the behavior? As a webpack user for over a year now, I still feel that the framework is very powerful—but that there are a number of default configurations that should be simpler to achieve. It is not clear that there is a worthy performance reason to not support long term caching by default, when it is not immediately clear that webpack requires additional configuration for long term caching in the first place.