-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
DependencyExtractionWebpackPlugin: Throw when using scripts from modules #57795
Changes from all commits
4ba4632
e018681
e4f147e
602162b
5860e6a
6d26ec1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,9 @@ module.exports = { | |
new DependencyExtractionWebpackPlugin( { | ||
combineAssets: true, | ||
requestToExternalModule( request ) { | ||
return request.startsWith( '@wordpress/' ); | ||
return ( | ||
request.startsWith( '@wordpress/' ) || request === 'lodash' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the module tests There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I noticed in the original PR that |
||
); | ||
}, | ||
} ), | ||
], | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
/* eslint-disable eslint-comments/disable-enable-pair */ | ||
/* eslint-disable eslint-comments/no-unlimited-disable */ | ||
/* eslint-disable */ | ||
|
||
import $ from 'jquery'; | ||
const apiFetch = await import( '@wordpress/api-fetch' ); | ||
|
||
$( () => { | ||
apiFetch( { path: '/' } ); | ||
} ); |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
/** | ||
* Internal dependencies | ||
*/ | ||
const DependencyExtractionWebpackPlugin = require( '../../..' ); | ||
|
||
module.exports = { | ||
plugins: [ | ||
new DependencyExtractionWebpackPlugin( { | ||
// eslint-disable-next-line no-unused-vars | ||
requestToExternal( request ) { | ||
throw new Error( 'Ensure error in script build.' ); | ||
}, | ||
} ), | ||
], | ||
}; |
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.
If we want to prevent bundling
@wordpress/*
modules by accident, then thedefaultRequestToExternalModule
should externalize everything@wordpress/*
by default. It's then the user's responsibility to add them to the importmap, otherwise the runtimeimport '@wordpress/x'
will fail.That's an approach identical to scripts, only instead of ensuring that scripts are
wp_enqueue
d we need to ensure that modules are in importmap.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.
If we really decide to treat
@wordpress/*
imports as an error by default, it's better to throw the error rather than return it.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're not there yet, as there are no
@wordpress
packages available as modules except for@wordpress/interactivity
.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.
My understanding is that we can't use scripts from modules at all at this time. Adding them to the import map wouldn't help because they don't export anything, they're not modules.
We can throw the error here, that's fine. We'll need to
try/catch
and pass it to the callback in the plugin (https://github.com/WordPress/gutenberg/pull/57795/files#r1450176826)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.
But even without this PR we will never use any actual WP script anyway. We'll either bundle a local
node_modules
package, or output an import of something that's expected to resolve to a ES module.If we keep this, it feels intuitively wrong to me to piggy-pack on
defaultRequestToExternal
. If we want to forbid@wordpress/*
, write it explicitly indefaultRequestToExternalModule
. Also, the error message will be very confusing if it prevents an import oflodash
,react
ormoment
. These are common NPM libraries, not WordPress-specific.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 share some of your reservations about this change. But I think that it's a good idea to provide this kind of feedback because during this scripts<->modules transition there's likely to be a lot of confusion and mistakes. This kind of change is intended to bring some clarity at an ideal time. It would help a lot of there were a post we could link to in the error message about the plans for this phase. @luisherranz is there anything public about scripts-modules compatibility we could link to?
This plugin is specific to WordPress. It can be used outside of WordPress, but that's not its primary purpose. If we do use it outside of WordPress, we should set
useDefaults: false
and we wouldn't get any errors.I piggy-backed on
defaultRequestToExternal
because the idea here is that if you're trying to use those scripts when compiling a Module for Wordpress, you're probably doing it wrong (at this time).defaultRequestToExternal
is a pretty good approximation of what scripts are available and what we're likely to see used. There may be legacy scripts that will never be available as modules and maybe we should maintain a list of those going forward.Some of those other modules probably work -
react
,lodash
,moment
- but I'd hate to have folks compiling a frontend module for multiple blocks and bundling those three dependencies in each one.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.
Alright, please go forward then 🙂 I don't have any other feedback.