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
Report dependencies externalized with Dependency Extraction Plugin #35106
Conversation
If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
Thank you for opening this Pull Request.
How people can access those articles? It's hard to understand how the changes proposed would benefit the WordPress project and the community without this context. The build process in Gutenberg and WordPress core replaces all WP dependencies with |
I created an issue in this repo #35630 This PR tries to address problem 5. stated there
That's exactly the DevX problem I'm trying to address here. Thanks to this PR a developer would at least know which of their local dependencies are extracted and which are not. So for which packages do they need to anticipate different versions. |
What do I have to provide to enable this option? Can you share a full example? |
I tested this new option by modifying the |
Thinking a bit more about it, if you want to see a full list of externalized dependencies you can enable |
I added more elaborate steps to reproduce in the OP #35106 (comment) Is that clearer now? |
Interesting. I didn't think
I thought it is to change the behavior of generating assets separately for each entry point to generating a single file. So to change the way it actually exposes the assets to be used on runtime. Also, for new DependencyExtractionWebpackPlugin( {
combineAssets: false,
outputFormat: 'json',
} ); it generates this list of internal identifiers {
"index.js": {
"dependencies": [
"lodash",
"moment",
"react",
"react-dom",
"wc-components",
"wc-navigation",
"wc-settings",
"wp-a11y",
"wp-api-fetch",
"wp-data",
"wp-data-controls",
"wp-date",
"wp-deprecated",
"wp-dom",
"wp-element",
"wp-hooks",
"wp-html-entities",
"wp-i18n",
"wp-is-shallow-equal",
"wp-keycodes",
"wp-polyfill",
"wp-priority-queue",
"wp-rich-text",
"wp-url",
"wp-warning"
],
// … instead of [
"@wordpress/i18n",
"@wordpress/hooks",
"@woocommerce/wc-admin-settings",
"@woocommerce/navigation",
"@wordpress/element",
"@woocommerce/components",
"@wordpress/data-controls",
"@wordpress/data",
"@wordpress/api-fetch",
"@babel/runtime/regenerator",
"@wordpress/url",
"@wordpress/date",
"lodash",
"moment",
"@wordpress/deprecated",
"@wordpress/a11y",
"@wordpress/html-entities",
"react",
"@wordpress/keycodes",
"@wordpress/priority-queue",
"react-dom",
"@wordpress/dom",
"@wordpress/is-shallow-equal",
"@wordpress/rich-text",
"@wordpress/warning"
] But that's pretty close, do you think we can somewhat merge those two together? |
Seems to me that the purposes of
|
@gziolo What's your take on the above comments? |
I think we should focus on bringing ES Modules and import maps to WordPress core to eventually make this plugin obsolete. It’s going to be a long process so if you think it’s helpful to add this feature then let’s land it.
Use the default filename - `'externalized-dependencies.json'` for `true`. Addresses WordPress#35106 (review)
One of the Continues Integration jobs fails even on subsequent re-tries: https://github.com/WordPress/gutenberg/runs/4261297083?check_suite_focus=true Can you check if rebasing with |
to report all dependencies extracted for the burrent build.
Use the default filename - `'externalized-dependencies.json'` for `true`. Addresses WordPress#35106 (review)
Thanks, @gziolo . Rebased, everything is green now. |
Report externaized dependencies to `/.externalized.json`. Help to inspect how wide range of granular dependencies we need to cover. Use `trunk` version of `@wordpress/dependency-extraction-webpack-plugin` to be able to use unreleased WordPress/gutenberg#35106
Report externa;ized dependencies to `/.externalized.json`. Help to inspect how wide is the range of granular dependencies we need to anticipate. Use `trunk` version of `@wordpress/dependency-extraction-webpack-plugin` to be able to use unreleased WordPress/gutenberg#35106
…35106) * Add `externalizedReportFile` option to DEWP, to report all dependencies extracted for the burrent build. * Add CHANGELOG.md entry. * Fix typo. * Update types.d.ts * Make DEWP's `externalizedReport` option accept booleans. Use the default filename - `'externalized-dependencies.json'` for `true`. Addresses #35106 (review) Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl>
@gziolo is there any date when this (and two other PRs) could be released to npm? - so it could be easily used outside |
We are in the process of releasing the next major WordPress version (5.9) so we don't do regular npm publishing every two weeks. I plan to run the development release with the |
Thank you for the info! BTW, I made a small improvement for this feature in #37377, maybe it could get into that release as well? |
Description
This PR adds a new option for plugin config
externalizedReportFile
, to report all dependencies exported for the current project.I need it as I try to build a tool that helps to inspect, analyze and manage the versions being used for local unit tests, and that runs with WordPress.
To compare the versions used locally, with the versions used in the range of supported WP builds.
edit:
This PR tries to address problem 5. from #35630
Thanks to this PR a developer would at least know which of their local dependencies are extracted and which are not. So for which packages do they need to anticipate different versions.
How has this been tested?
I run this code against
https://github.com/woocommerce/google-listings-and-ads repo's webpack config with and without the new option.
node_modules/@wordpress/dependency-extraction-webpack-plugin
with the changed one from this PRpackages/dependency-extraction-webpack-plugin
.Without the new option
npm run build
/js/build/index.js
bundle is created as before.With the new option
reportExternalized
option to the/webpack.config.js#L79-L83
:npm run build
/js/build/index.js
bundle is created as before./js/build/externalized.js
is created and contains:Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
npm install
for entire repo fails on my machine*.native.js
files for terms that need renaming or removal).The text was updated successfully, but these errors were encountered: