Add in asset filename filtering via {test, include, exclude} #1149
Conversation
| @@ -31,6 +31,9 @@ | |||
| "json-stable-stringify": "^1.0.1", | |||
| "workbox-build": "^3.0.0-alpha.3" | |||
| }, | |||
| "peerDependencies": { | |||
| "webpack": "^2.0.0 || ^3.0.0" | |||
There was a problem hiding this comment.
This seems unusual to me, is it stipulating that workbox only works with Webpack 2 and 3 (i.e. not 4)?
There was a problem hiding this comment.
I am following UglifyJS's lead here in limited the acceptable peer dependency: https://github.com/webpack-contrib/uglifyjs-webpack-plugin/blob/025262284c86196d0a4c4fe71e186132579629ec/package.json#L75-L77
(My understanding is that webpack 4 changes the plugin architecture anyway, so I think we should track that separately: #1151)
| @@ -177,6 +179,13 @@ function getManifestEntriesFromCompilation(compilation, config) { | |||
|
|
|||
| const manifestEntries = []; | |||
| for (const [file, metadata] of Object.entries(filteredAssetMetadata)) { | |||
| // Filter based on test/include/exclude options set in the webpack config. | |||
There was a problem hiding this comment.
Can you just add a comment on the end of this sentence along the lines "This matches behaviour of uglifyJS". Copying and pasting links is O.T.T. to get the gist of the point your are getting across.
There was a problem hiding this comment.
It would also be worth calling out that we can take advantage of webpacks built in filtering (which for me is a better reason for this approach over something uglify does).
R: @jeffposnick @addyosmani @gauntface
CC: @anilanar
Fixes #935
As mentioned in the comments/the original issue, this takes advantage of a pattern native to webpack and used in other plugins (like UglifyJS) for filtering the precache manifest of webpack assets based on an object with
test,include, andexcludeproperties.It defaults to using RegExps for
excludethat will match.mapfiles andmanifest*.js(on)files. While webpack gives developers flexibility to name their sourcemaps and asset manifest files whatever they'd like, those seem like the most common naming schemes (and they can be overridden).The drawback of this PR is that it makes filtering more complicated: prior to this PR we implemented filtering based on chunk name white/blacklists, and now this introduces filtering based on asset name white/blacklists. (The chunk filtering is run first, then asset filtering.) There seems to be developer demand for supporting both, but this is another thing to try to explain clearly in the docs update (google/WebFundamentals#5567).