Scripts: Add CSS support to start and build scripts #21730
Conversation
gziolo
requested review from
ajitbohra,
nerrad,
ntwb and
youknowriad
as code owners
gziolo
added
[Package] Scripts
|
Size Change: +287 kB (25%) 🚨 Total Size: 1.12 MB
ℹ️ View Unchanged
|
@mor10 – just to make sure, do we cover the use cases with the current proposal? I'm not much into the specifics of CSS support in webpack but I'm motivated to land the initial implementation :) |
@kadamwhite – I echo all that. I heard similar questions so many times. I also had to help people to fix issues caused by the their own try to add it to the default config that I'm in the position that it's more beneficial in terms of maintenance to add CSS support to |
|
I think I figured out how to add CSS import support to |
| @@ -29,9 +29,7 @@ | |||
| ], | |||
| "main": "index.js", | |||
| "dependencies": { | |||
| "autoprefixer": "^9.4.5", | |||
There was a problem hiding this comment.
It turns out all 3 packages aren't used in the package ...
| splitChunks: { | ||
| cacheGroups: { | ||
| styles: { | ||
| name: 'style', |
There was a problem hiding this comment.
The interesting part here is that all other styles that don't match the regular expression included in test get combined into another chunk that is named after an entry point:
index.js -> index.css
It even works with multiple entry points:
one.js -> one.css
two.js -> two.css
All files that end with style.(sc|sa|c) are combined into one file -> style.css
There was a problem hiding this comment.
@gziolo When I try to import css files with a name different from style.(sc|sa|c)ss everything just gets dumped into one chunk called index.css. Which is not what you described here?
There was a problem hiding this comment.
@fabiankaegy what you described is exactly what I was trying to explain in my comment. It looks like I did it poorly 🙃
I made the following assumption – you are writing JavaScript code for the block editor so it's going to be used in WP-Admin only. That's why all imported CSS files are dumped into one chunk named after the entry point which is index.js and thus index.css by default. Now, when you use import style.css; (or with different file extensions) it gets bundled into style.css file that is meant to be used both on the front-end and in the editor. Does it make sense?
There was a problem hiding this comment.
Okay so with that the workflow would be enqueueing the index.css file in the editor and the style.css in the both places?
There was a problem hiding this comment.
If so that’s fine but since in one case the naming of the imported file is used and in the other place it isn’t I think this needs to be made clear in the documentation.
My initial gut feeling of how it should work was that it automatically combines all files with the same name into a chunk with that name.
There was a problem hiding this comment.
Yes, it's all correct. Documentation is quite important here :)
It reminds also about the second reason why I opted for style to be tackled differently. You can have multiple entry points as described in the docs:
wp-scripts start entry-one.js entry-two.js --output-path=customIn fact, you can also have still one entry point and name it differently if you will. The chances that you name an entry point style is close to zero. If we would flip the approach and make editor.(sc|sa|c)ss special case, the chances that someone would name their chunk editor would be much higher.
|
Currently the |
I wasn't aware that |
|
I updated the description and included all the details on how I tested this PR. The only missing part is documentation in the advanced section of |
Co-authored-by: Kelly Dwan <ryelle@users.noreply.github.com>
| "minimist": "^1.2.0", | ||
| "node-sass": "^4.13.1", |
There was a problem hiding this comment.
I hope we don't come to regret foisting this troublesome dependency upon consumers of @wordpress/scripts 😬
There was a problem hiding this comment.
It is what it is, we use it in Gutenberg as well.
There was a problem hiding this comment.
Maybe separately, it's something to consider to the general problem of the amount (and difficulty) of the specific dependencies we ship here. Whether it's something we can defer with some sort of lazy importing, or splitting off to more granular packages, or some sort of peer dependency pattern to leverage the features the developer opts in to.
I just worry that @wordpress/scripts tries to do everything and the pattern to ship it all in the same package this way won't doesn't scale well to accommodate.
There was a problem hiding this comment.
Though, to be clear, my issue with SASS dependency specifically is less of size, and more of how it's built from source, and all the usability problems that stem from this (e.g. Node version correspondence).
There was a problem hiding this comment.
I would suggest changing this to Dart SASS (sass package). It's the primary implementation for SASS, and saves contributors all the native compilation trouble node-sass brings. sass-loader picks it up without any additional configuration.
|
|
||
| When you run the build using the default command `wp-scripts build` (also applies to `start`) in addition to the JavaScript file `index.js` generated in the `build` folder, you should see two more files: | ||
| 1. `index.css` – all imported CSS files are bundled into one chunk named after the entry point, which defaults to `index.js`, and thus the file created becomes `index.css`. This is for styles used only in the editor. | ||
| 2. `style.css` – imported `style.css` file(s) (applies to SASS and SCSS extensions) get bundled into one `style.css` file that is meant to be used both on the front-end and in the editor. |
There was a problem hiding this comment.
Have we previously made such assumptions about how @wordpress/scripts is used for bundling for the editor, vs. being purely general-purpose in its goals? I need to spend some time to look at some of the history here.
There was a problem hiding this comment.
It's something I proposed based on the previous implementation from #14847, an article from @phpbits https://jeffreycarandang.com/create-gutenberg-block-plugin-wp-scripts-postcss-build/, create-guten-block (https://github.com/ahmadawais/create-guten-block/blob/bdc40192fc7fa30519d821e2aa835b2aa6ef7534/packages/cgb-scripts/config/webpack.config.prod.js#L109-L118) or the old implementation in Gutenberg before we moved to packages. I made an assumption that it became a standard approach in the community.
|
I plan to merge this PR at the end of the week to ensure it's included in the npm release that should happen next week. |
|
Thank you all for making this happen. Let’s iterate based on feedback from the people using it in their projects 🎉 |
|
It's now published to npm as part of |
NOTE: [this @wordpress/scripts pr](WordPress/gutenberg#21730) breaks mini-css-extract functionality. Upgrading @wordpress/scripts above 9.0.0 WILL break our webpack config
NOTE: [this @wordpress/scripts pr](WordPress/gutenberg#21730) breaks mini-css-extract functionality. Upgrading @wordpress/scripts above 9.0.0 WILL break our webpack config
* chore: dependency updates and optimization NOTE: [this @wordpress/scripts pr](WordPress/gutenberg#21730) breaks mini-css-extract functionality. Upgrading @wordpress/scripts above 9.0.0 WILL break our webpack config * fix: update child theme handle
* chore: dependency updates and optimization NOTE: [this @wordpress/scripts pr](WordPress/gutenberg#21730) breaks mini-css-extract functionality. Upgrading @wordpress/scripts above 9.0.0 WILL break our webpack config * fix: update child theme handle
Description
Closes #14801.
This PR adds new capability to
buildandstartscripts that automates handling CSS, SASS or SCSS files by importing them from JavaScript code.More details about assets management in webpack at https://webpack.js.org/guides/asset-management/.
It builds upon the work @fabiankaegy started in #14847 where he added loaders for CSS, SCSS/SASS that compile and afterward run PostCSS.
It is heavily influenced by the solution shared by @phpbits in https://jeffreycarandang.com/create-gutenberg-block-plugin-wp-scripts-postcss-build/.
Implementation details
I made the following assumptions:
index.jsand thus it becomesindex.cssby default. Now, when you useimport style.css;(or with different file extensions) it gets bundled intostyle.cssfile that is meant to be used both on the front-end and in the editor.styleto be tackled differently. You can have multiple entry points as described in the docs:styleis close to zero. If we would flip the approach and makeeditor.(sc|sa|c)ssa special case, the chances that someone would name their chunkeditorwould be much higher.New npm package
I had to extract a new WordPress npm package
@wordpress/postcss-configthat allows sharing PostCss configuration between@wordpress/scripts, Storybook configuration and Gutenberg script that builds local packages.How has this been tested?
This is how I tested it inside Gutenberg:
npx wp-create-block my-test-blockto generate some random block with@wordpress/scriptssetup.my-test-block/src/editor.scsswith some styles for the editor.my-test-block/src/style.scsswith some styles for both the front-end and the editor.my-test-block/src/index.jsto import both files created:@wordpress/scriptsrather than the one bundled in the scaffolded plugin.webpack.config.jsfile to letwp-scriptsuse the default config provided.npx wp-scripts build my-test-block/src/index.js --output-path "my-test-block/build"my-test-block/buildfolder:index.css– containing content fromsrc/editor.scssstyle.css– containing content fromsrc/style.scssTesting multiple entry points
Bonus points are for testing multiple entry points with the following command:
npx wp-scripts build my-test-block/src/index.js my-test-block/src/other-file.js --output-path "my-test-block/build"It requires adding
other-file.jsand some additional import statements pointing to CSS files. It should produce 3 CSS files:index.css– containing content fromsrc/editor.scsslisted inindex.jsother-file.css– containing content referenced in the additionalother-file.jsfilestyle.css– containing content fromsrc/style.scssor other files that end withstyle.(sc|sa|c)ssTesting
@wordpress/postcss-configI also ensured that Gutenberg and Storybook still work:
npm run devnpm run storybook:devTypes of changes
New feature (non-breaking change which adds functionality).
Checklist: