-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle CSS build process with Webpack #6057
Conversation
So far, all stylesheets that were not imported in JS files were handled with plain CLI commands. The simple "build" process consisted of copying all CSS files from `./assets/css/src` to `./assets/css` and generating RTL stylesheets with the `rtlcss` CLI command. With this update, all files in the `./assets/css/src` folder are handled by the new 'Styles' Webpack entry point. Thanks to that, they are watched and rebuilt on-the-fly with the regular `npm run dev` task. Also, it is now possible to use the SASS/SCSS preprocessing, if needed.
Plugin builds for 075b1ae are ready 🛎️!
|
Since the CI complained about missing |
Doesn't this cause tons of empty JS chunks for these CSS files? |
@swissspidy Well, yes, it does. Obviously, not the nicest side effect. Do you think there's a way to get rid of them? |
It seems that it's possible to not generate those empty chunks by using the This, along with the previous commit that disables the |
Makes sense. I've removed all traces of |
Comparing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The output looks great.
The webpack config changes I'm not very familiar with, so I request @pierlon to verify.
Otherwise, looks great to merge!
@@ -340,6 +341,80 @@ const settingsPage = { | |||
], | |||
}; | |||
|
|||
const styles = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that Gutenberg had a similar problem and so created the FixStyleWebpackPlugin
plugin to prevent those JS chunks from being generated. That plugin would only apply chunk assets that match the style
cache group, however (that is, it would only apply to files named style.css
).
Although the plugin is included in sharedConfig.plugins
, it would not be applying anything as we're not including the aforementioned style
optimization cache group.
...sharedConfig.plugins.filter( | ||
( plugin ) => plugin.constructor.name !== 'DependencyExtractionWebpackPlugin', | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be necessary if the IgnoreEmitPlugin
plugin was before the DependencyExtractionWebpackPlugin
plugin, but this works 👍.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to avoid adding that but haven't thought about the order of the plugins and so the .asset.php
files were always generated. I guess we could improve the implementation in the future.
webpack.config.js
Outdated
const match = entryPath.match( /^.*\/(.*)\..*$/ ); | ||
|
||
return match && match[ 1 ] ? `${ match[ 1 ] }.js` : null; | ||
} ) | ||
.filter( Boolean ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the match
regex need to be this generic? Since all the entry points are CSS files this could be made simpler:
const match = entryPath.match( /^.*\/(.*)\..*$/ ); | |
return match && match[ 1 ] ? `${ match[ 1 ] }.js` : null; | |
} ) | |
.filter( Boolean ); | |
const match = entryPath.match( /([^\/]+)\.s?css$/ ); | |
return `${ match[ 1 ] }.js`; | |
} ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The entry points may also be SCSS files, but I guess the regex could still get simplified to something like:
/([^\/]+)\.s?css$/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, that works as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pierlon Would you apply that change and verify it produces the expected output? Then we can merge this PR if I'm not mistaken, at least for beta2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed that an empty JS chunk is also being generated for the wp-components
entrypoint on the "Settings page" webpack config. We can either move it to the "Styles" webpack config, or extract these set of changes into a new webpack plugin so that we can apply it to multiple webpack configs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can go for the former right now, and then deal with the latter later on. I can create an issue for that if needed.
QA passed. |
Summary
So far, all stylesheets that were not imported in JS files were handled with plain CLI commands. The simple "build" process consisted of copying all CSS files from
./assets/css/src
to./assets/css
and generating RTL stylesheets with thertlcss
CLI command.With this update, all files in the
./assets/css/src
folder are handled by the new 'Styles' Webpack entry point. Thanks to that, they are watched and rebuilt on the fly with the regularnpm run dev
task. Also, it is now possible to use the SASS/SCSS preprocessing, if needed.Checklist