-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add packages webpack config WiP #118
Conversation
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.
Thanks for starting this 👍
|
||
return mediaConfig; | ||
return config; |
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.
Is this array of multiple configs something webpack supports by default? I wasn't aware of it :)
Ideally, media could be just another package but I can see how this may be needed for some time.
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 completely agree, I chose this approach pragmatically because I didn't want to touch the media config if possible.
tools/webpack/packages.js
Outdated
'blocks', | ||
// 'block-library', // Not on npm yet. | ||
'block-serialization-default-parser', | ||
// 'block-serialization-spec-parser', // No build-module folder. |
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.
It's fine to not have build-module
in a package. Webpack should default to build
automatically when you import "package"
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.
block-serialization-spec-parser
- as far as I know we use only block-serialization-default-parser
- the other exists only as an alternative solution which was replaced by block-serialization-default-parser
.
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.
Using @wordpress/[package]
doesn't work because is is also an external. In Gutenberg this is not a problem because the packages are referred to by their relative path. Given we want to have 1 monorepo for the whole of WordPress in the end I think we can hard-code build-module
for now.
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 will fix it for those two packages though.
tools/webpack/packages.js
Outdated
const packagesStyles = [ | ||
'nux', | ||
'components', | ||
'editor', |
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 missed edit-post
here in my PR :)
moment: 'moment', | ||
jquery: 'jQuery', | ||
lodash: 'lodash', | ||
'lodash-es': 'lodash', |
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.
These externals are mostly downloaded by Gutenberg at build time. For WordPress, we should just add them as npm dependencies and bundle them as scripts (like the WordPress packages). You can see how I did that for lodash in this patch https://core.trac.wordpress.org/ticket/44987
(expect jQuery and tinymce of course which are already there)
tools/webpack/packages.js
Outdated
}, {} ), | ||
output: { | ||
filename: `[name]${ suffix }.js`, | ||
path: join( baseDir, 'js/dist' ), |
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.
Shouldn't we produce the built files in wp-includes
or something like that?
tools/webpack/packages.js
Outdated
return memo; | ||
}, {} ), | ||
output: { | ||
filename: `[name]${ suffix }.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.
We use basename
in Gutenberg here (thanks to the CustomTemplatedPathPlugin
plugin applied in the config). This allows us to have dashes in file names and camelCase in the global (library config).
} | ||
|
||
return config; | ||
}; |
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 suppose we need also a babel config and a dedicated rule essentially to extract the i18n messages since the rest is already taken care of in the published packages.
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 will put extracting the i18n on my list as a follow-up task, I think we should get this in first though.
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'm fine delaying it to a separate commit :)
Should we add all these new scripts into the "script-loader.php". cc https://core.trac.wordpress.org/ticket/44987 for inspiration. |
tools/webpack/packages.js
Outdated
'hooks', | ||
'html-entities', | ||
'i18n', | ||
// 'is-shallow-equal', // No build-module folder. |
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.
There is not going to be build-module
, nor build
folder for this package.
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.
We shouldn't assume packages need build-module or build folder or anything. require
or import
(or point to the root folder) and let webpack do its magic.
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 thinking was that we want WordPress to become a mono-repo with these packages in time so hardcoding build-module
for now is fine.
Also using @wordpress/[package]
doesn't work because that is also defined as external and then these build files don't contain anything.
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 have a mono-repo structure (like Gutenberg does) without hardcoding build-module
. I do see this as an artificial barrier for package inclusion as all packages are not compiled (thus have a build-module
folder)
There is a lot of duplication between Webpack in both Gutenberg and what is proposed in core. I'm wondering if we should try to find what's common and expose as a npm package to simplify maintenance. |
For the record, we should land WordPress/gutenberg#10429 soon. I'm doing the last round of testing. This is the last blocker for publishing all Gutenberg codebase to npm. I will take care of it tomorrow as the first thing. |
tools/webpack/vendors.js
Outdated
|
||
const vendors = { | ||
'lodash': 'lodash', | ||
'wp-polyfill': '@babel/polyfill', |
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 one is more than that actually but it's mostly handled via add_inline_script to avoid loading more than what we really need, but it also means we need to include here all these dependencies (fetch polyfill, element-closest, form-data, node-contains. We also need TinyMCE list plugin (not sure if this one is already in Core though)
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 added the other polyfills. Core has the TinyMCE lists plugin, what was the reason that Gutenberg included it? Just to get the latest version?
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.
Looks like core already has the required version of TinyMCE: https://core.trac.wordpress.org/changeset/43472. Even in the 5.0 branch.
tools/webpack/vendors.js
Outdated
{ | ||
packageName: 'react-dom', | ||
global: 'ReactDOM', | ||
}, |
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 feel some of these packages don't need globals. Is it concerning that we always attach a global?
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.
More globally, I wonder if we should use webpack to include these scripts or just "copy" task to copy from node_modules into a given directory in Core. It feels like all these packages already have built files with globals etc...
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 checked all the vendors and they all already have build versions, so I changed this to use the Webpack copy plugin: 25dcd5e. 3 packages didn't have minified files, so I used uglify to minify those.
tools/webpack/packages.js
Outdated
'wordcount', | ||
]; | ||
|
||
const packagesStyles = [ |
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 noticed that in Gutenberg we don't have this second variable and we just rely on this line https://github.com/Yoast/wordpress-develop-mirror/pull/118/files#diff-df0280933db62a33cd94973b5ec4871eR167 to know whether or not there are files to move and minify.
Any particular reason for this here? I'm thinking this may result in some CSS to be missed if we ever add CSS to another package.
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 tested this before and it didn't work, but now that I test it it works. I agree that that's more elegant, considering the case a package adds styles.
entry: gutenbergPackages.reduce( ( memo, packageName ) => { | ||
const name = camelCaseDash( packageName ); | ||
memo[ name ] = join( baseDir, `node_modules/@wordpress/${ packageName }` ); | ||
return memo; |
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.
Actually, this is pretty interesting as we could reference node_modules/@wordpress/${ packageName }
also from Gutenberg itself. Just noting in case we would like to have shared code to rule them all :)
For reference:
https://github.com/WordPress/gutenberg/blob/master/webpack.config.js#L134
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 is looking good to me. We can't effectively test this at the moment, until we have the script registration on the server which I'm fine delaying until another commit.
Also, yes, let's wait for the npm releases which should happen quickly. I'll keep you updated.
@@ -50,35 +50,41 @@ | |||
}, | |||
"dependencies": { | |||
"@babel/polyfill": "^7.0.0", |
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.
We might need also
"@babel/runtime-corejs2": "7.0.0",
as a dependency. Now, I think about it, it probably should be dependency
inside Gutenberg as it is referenced inside generated JavaScript.
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.
We need to test it with PHP part, but overall this looks great. I really like the way you handled mapping between all external libraries (including polyfills) - everything is very clean. Let's move on and iterate when PHP part is moved into core.
@@ -0,0 +1,33 @@ | |||
var path = require( 'path' ), |
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.
Super minor: we could replace var
with const
to improve aesthetics :)
@@ -38,7 +42,56 @@ | |||
"grunt-webpack": "^3.0.2", | |||
"ink-docstrap": "^1.3.0", | |||
"matchdep": "~2.0.0", | |||
"source-map-loader": "^0.2.4", | |||
"uglify-js": "^3.4.9", |
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 may cause issues, a conflict issue with grunt-contrib-uglify
was reverted a couple of days ago via https://core.trac.wordpress.org/changeset/43686/
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.
It doesn't say why it was reverted. But it might not be a problem because node_modules
can deal with different versions of the same package. At least for dev dependencies.
No description provided.