WP Scripts: Build block.json viewModule #57461
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: 0 B Total Size: 1.69 MB ℹ️ View Unchanged
|
sirreal
force-pushed
the
add/wp-scripts-view-module
branch
from
8a38d83
to
99b05ff
Compare
sirreal
force-pushed
the
add/wp-scripts-view-module
branch
2 times, most recently
from
588dba4
to
8e4ea2a
Compare
|
This pull request changed or added PHP files in previous commits, but none have been detected in the latest commit. Thank you! ❤️ |
sirreal
force-pushed
the
add/wp-scripts-view-module
branch
4 times, most recently
from
a127bbb
to
42286a3
Compare
sirreal
added
[Feature] Block API
sirreal
force-pushed
the
add/wp-scripts-view-module
branch
from
42286a3
to
7f850e2
Compare
sirreal
requested review from
gziolo,
ntwb,
nerrad,
ajitbohra and
ryanwelcher
as code owners
sirreal
changed the title
|
I spent some time thinking about the problem of colliding assets and I think we should explore changing the output directories of script and module assets. This could mean things like CSS duplication, but I think we're unlikely to have both That should make the cleaning strategies simpler as builds would have more control over their output directories. I think something like this would be good, but I do want to do some testing: That doesn't need to block review of this PR, it can be landed and we can iterate on the output strategy. |
gziolo
reviewed
Jan 8, 2024
gziolo
reviewed
Jan 8, 2024
| if ( ! isProduction ) { | ||
| // Set default sourcemap mode if it wasn't set by WP_DEVTOOL. | ||
| baseConfig.devtool = baseConfig.devtool || 'source-map'; | ||
| baseConfig.devServer = { |
There was a problem hiding this comment.
Will two configs integrate seamlessly with a single dev server that uses shared setup?
There was a problem hiding this comment.
Good spot, this needs to be configured with different ports.
There was a problem hiding this comment.
It looks like devServer doesn't really work with multiple compilations: webpack/webpack-cli#2408
I'll only add this to 1 config.
gziolo
reviewed
Jan 8, 2024
gziolo
reviewed
Jan 8, 2024
| // MiniCSSExtractPlugin to extract the CSS thats gets imported into JavaScript. | ||
| new MiniCSSExtractPlugin( { filename: '[name].css' } ), | ||
| // React Fast Refresh. | ||
| hasReactFastRefresh && new ReactRefreshWebpackPlugin(), |
There was a problem hiding this comment.
I don’t think React Fast Refresh will work out of the box for viewModule.
There was a problem hiding this comment.
I think it may work, but I'm not really sure how to test. Interactivity uses preact, which I don't think is compatible with the react refresh work. I saw this issue about refresh support for preact preactjs/preact#2184
We probably just remove this for now for modules.
There was a problem hiding this comment.
sirreal
force-pushed
the
add/wp-scripts-view-module
branch
from
edb3d11
to
a1192fc
Compare
1 task
sirreal
force-pushed
the
add/wp-scripts-view-module
branch
from
74187e2
to
d59256a
Compare
|
|
I put together a proposal in #57761 that outputs different assets to different directories, but I'm not completely happy with it. I now think that there is less likelihood of assets colliding because assets are named based on files in the src directory. Different assets can't have the same name because they would be the same src file (technically they probably could, but that's unlikely to happen in reality at this time). Let's see what happens while folks use module builds and whether there's a problem in practice. |
gziolo
reviewed
Jan 11, 2024
| @@ -317,52 +380,55 @@ const config = { | |||
| process.env.WP_BUNDLE_ANALYZER && new BundleAnalyzerPlugin(), | |||
| // MiniCSSExtractPlugin to extract the CSS thats gets imported into JavaScript. | |||
| new MiniCSSExtractPlugin( { filename: '[name].css' } ), | |||
| // React Fast Refresh. | |||
There was a problem hiding this comment.
It looks like React Fast Refresh was misplaced. It should remain here for the scripts configuration as it works withe the existing Babel config and the dev server.
It won’t work with the modules config as it’s missing proper Babel handling, the dev server integration. In addition, I’m not sure whether it’s even possible to make it work with Preact.
There was a problem hiding this comment.
You're absolutely correct, thanks: #57777
sirreal
added a commit
that referenced
this pull request
Jan 11, 2024
Restore ReactRefreshWebpackPlugin to @wordpress/scripts webpack config. #57461 accidentally moved the plugin to the modules config. It should have remained in the scripts webpack config and not been included in the modules config.
sirreal
added a commit
that referenced
this pull request
Jan 15, 2024
Restore ReactRefreshWebpackPlugin to @wordpress/scripts webpack config. #57461 accidentally moved the plugin to the modules config. It should have remained in the scripts webpack config and not been included in the modules config.
gziolo
pushed a commit
that referenced
this pull request
Jan 16, 2024
Restore ReactRefreshWebpackPlugin to @wordpress/scripts webpack config. #57461 accidentally moved the plugin to the modules config. It should have remained in the scripts webpack config and not been included in the modules config.
|
How to change the previously working webpack additional config? I mean I was using something like this to add additional entrypoint: Now this is not working anymore. I got the error Can you please explain how to handle module compilation with multiple entrypoint? |
gziolo
reviewed
Jan 17, 2024
| const scriptConfig = { | ||
| ...baseConfig, | ||
|
|
||
| entry: getWebpackEntryPoints( 'script' ), |
There was a problem hiding this comment.
This needs to be refactored back to a callback function. There are two reasons:
- compatibility with the existing projects that override entry points
- more importantly, entry points are recomputed in the watch mode anymore
There was a problem hiding this comment.
It is a callback, the signature changed so this now returns the callback:
gutenberg/packages/scripts/utils/config.js
Lines 188 to 202 in 05b6bd7
I'm investigating the problem now.
There was a problem hiding this comment.
more importantly, entry points are recomputed in the watch mode anymore
Do you mean if I change block.json (to add another file) when wp-scripts start --experimental-modules is running, the build doesn't pick it up?
I don't think this has changed at all for script builds or for the script compilation of module builds. I believe the copy webpack plugin is adding the block.json files to the build which makes webpack observe those changes.
Because the modules compilation doesn't include the copy plugins for block.json, when block.json changes the module compilation won't pick it up. I'll look into how to make it observe those changes.
There was a problem hiding this comment.
It looks like it should work correctly for scripts when the is no experimental flag provided 👍
There was a problem hiding this comment.
Here's a PR to add block.json files as webpack file dependencies so they're watched from the module build: #57927
Thanks for the report @Tropicalista. These changes were not intended the modify the webpack config (unless you've opted in to experimental module compilation). I'll investigate. |
I'm sorry, I missed that this was for module compilation, so the build is being run with the @Tropicalista With experimental module compilation we don't support using the webpack configuration directly for extension like in your example. Module compilation via this package is experimental and we need to be able to change or remove the module configuration. In the future, module compilation may not even be handled via webpack. The main issue for discussing this module integration is #57492. Not considering the module webpack config to be public is one of the decisions we made at least for this first version:
|
scruffian
pushed a commit
that referenced
this pull request
Jan 17, 2024
Restore ReactRefreshWebpackPlugin to @wordpress/scripts webpack config. #57461 accidentally moved the plugin to the modules config. It should have remained in the scripts webpack config and not been included in the modules config.
This was referenced Jan 17, 2024
This was referenced Feb 6, 2024
fabiankaegy
added
the
Needs Dev Note
32 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Add handling of
viewModulefield in block.json when usingwp-scriptsbuildorstart.Part of #57492
Why?
As the Modules API matures, our tooling should support it.
How?
We add an option to clearly mark this an an experimental feature:
wp-scripts build --experimental-modules.To support modules with webpack, it was necessary to run a multi-compilation. We use an array of webpack configurations instead of a single webpack configuration. This is because module compilation is an option at the compilation level and cannot be set for specific entrypoints.
If the
--experimental-modulesoption is found, we use an environment variable to change thewebpack.configexport to return an array[ scriptWebpackConfig, moduleWebpackConfig ]. Without the experimental option, thewebpack.configexport is the same except for changes that should not impact the script build at all. Consumers should be able to continue extending this config without noticing any differences. I introduced a snapshot test to compare the results, the difference is currently at 20dff00. I did subsequently remove this test as it doesn't seem to have long-term value.Notable changes to the existing webpack config: None.
experiments.outputModulewebpack option is set totrue. This enables module compilation, but module compilation is controled by other options (output.module). This should not impact existing builds.As mentioned above, if we find the
WP_EXPERIMENTAL_MODULESenvironment variable (set by adding the--experimental-modulesoption on the CLI) then the webpack config will export an array of configs.If we run in experimental modules mode, the
CleanWebpackPlugincould remove assets that should be included. This is because both compilations output to the same output directory. Ideally, each compilation would have control over its output directory and not share them. That's difficult and I don't have a good solution at this time given that we do want to share other assets like stylesheets. Additionally, if we were to output to different directories, the block.jsonfile:…rewriting would need to account for that.I don't have a convincing solution for either using multiple directories or preventing assets from being clobbered at this time. Given that this is clearly flagged as experimental, I believe that's acceptable and we can improve things if a convincing solution presents itself.
Since this is experimental, I wanted avoided adding more webpack configuration files. I don't want to expose more files that could folks require and extend. We could consider adding an
exportsfield to this package to control access to certain things, but that's likely a breaking change I didn't want to undertake here.Testing Instructions
To test this, you'll want to check this out and link a project that depends on
@wordpress/scriptsto use this PR.If you use
wp-scripts buildorwp-scripts start, there should be no significant changes with the current behavior.You can test the experimental build by adding a
viewModulefield to block.json in a project, then running a script likewp-scripts -- build --experimental-modulesto build it.I've been running the experimental build of https://github.com/sirreal/wp-scripts-interactivity-module-demo (the packages is linked to my development copy locally). The build produces the expected results with both scripts and modules. With #57437 (handling
viewModulein block registration), this results in a working plugin. Here's the build ouptut:block.json{ "$schema": "https://schemas.wp.org/trunk/block.json", "apiVersion": 3, "title": "Jon's cool counter", "name": "jon/the-block", "editorScript": "file:./index.js", "viewModule": "file:./view.js", "render": "file:./render.php", "category": "text" }index.asset.phpindex.jsrender.php<div data-wp-interactive='{"namespace":"jon/the-block"}' data-wp-context='{"val":0}'> <input readonly type='number' data-wp-bind--value='context.val' value='0' /> <button data-wp-on--click='actions.inc'>+</button> <button data-wp-on--click='actions.dec'>-</button> </div>view.asset.phpview.js