Add packages webpack config WiP by atimmer · Pull Request #118 · Yoast/wordpress-develop-mirror

atimmer · 2018-10-09T12:24:05Z

No description provided.

youknowriad

Thanks for starting this 👍

youknowriad · 2018-10-09T12:26:29Z

+	];

-	return mediaConfig;
+	return config;


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.

I completely agree, I chose this approach pragmatically because I didn't want to touch the media config if possible.

youknowriad · 2018-10-09T12:28:27Z

+		'blocks',
+//		'block-library', // Not on npm yet.
+		'block-serialization-default-parser',
+//		'block-serialization-spec-parser', // No build-module folder.


It's fine to not have build-module in a package. Webpack should default to build automatically when you import "package"

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.

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.

I will fix it for those two packages though.

youknowriad · 2018-10-09T12:29:25Z

+	const packagesStyles = [
+		'nux',
+		'components',
+		'editor',


I missed edit-post here in my PR :)

youknowriad · 2018-10-09T12:31:20Z

+		moment: 'moment',
+		jquery: 'jQuery',
+		lodash: 'lodash',
+		'lodash-es': 'lodash',


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)

youknowriad · 2018-10-09T12:32:52Z

+		}, {} ),
+		output: {
+			filename: `[name]${ suffix }.js`,
+			path: join( baseDir, 'js/dist' ),


Shouldn't we produce the built files in wp-includes or something like that?

youknowriad · 2018-10-09T12:37:28Z

+			return memo;
+		}, {} ),
+		output: {
+			filename: `[name]${ suffix }.js`,


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).

youknowriad · 2018-10-09T12:39:21Z

+	}
+
+	return config;
+};


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.

I will put extracting the i18n on my list as a follow-up task, I think we should get this in first though.

I'm fine delaying it to a separate commit :)

youknowriad · 2018-10-09T12:40:15Z

Should we add all these new scripts into the "script-loader.php". cc https://core.trac.wordpress.org/ticket/44987 for inspiration.

gziolo · 2018-10-09T12:44:04Z

+		'hooks',
+		'html-entities',
+		'i18n',
+//		'is-shallow-equal', // No build-module folder.


There is not going to be build-module, nor build folder for this package.

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.

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.

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)

gziolo · 2018-10-09T12:45:55Z

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.

gziolo · 2018-10-09T14:59:02Z

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.

youknowriad · 2018-10-09T15:43:09Z

+
+	const vendors = {
+		'lodash': 'lodash',
+		'wp-polyfill': '@babel/polyfill',


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)

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?

Looks like core already has the required version of TinyMCE: https://core.trac.wordpress.org/changeset/43472. Even in the 5.0 branch.

youknowriad · 2018-10-10T10:05:47Z

+		{
+			packageName: 'react-dom',
+			global: 'ReactDOM',
+		},


I feel some of these packages don't need globals. Is it concerning that we always attach a global?

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...

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.

youknowriad · 2018-10-10T10:09:10Z

+		'wordcount',
+	];
+
+	const packagesStyles = [


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.

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.

gziolo · 2018-10-10T11:37:47Z

+		entry: gutenbergPackages.reduce( ( memo, packageName ) => {
+			const name = camelCaseDash( packageName );
+			memo[ name ] = join( baseDir, `node_modules/@wordpress/${ packageName }` );
+			return memo;


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

youknowriad

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.

gziolo · 2018-10-11T08:33:20Z

@@ -50,35 +50,41 @@
  },
  "dependencies": {
    "@babel/polyfill": "^7.0.0",


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.

gziolo

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.

gziolo · 2018-10-11T08:41:25Z

@@ -0,0 +1,33 @@
+var path         = require( 'path' ),


Super minor: we could replace var with const to improve aesthetics :)

ntwb · 2018-10-11T10:37:09Z

    "ink-docstrap": "^1.3.0",
    "matchdep": "~2.0.0",
+    "source-map-loader": "^0.2.4",
+    "uglify-js": "^3.4.9",


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/

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.

Add packages webpack config WiP

3c96347

youknowriad reviewed Oct 9, 2018

View reviewed changes

gziolo reviewed Oct 9, 2018

View reviewed changes

Include more packages and don't watch on dev build

95a1de6

Add vendors with their own webpack config

68c967a

youknowriad reviewed Oct 9, 2018

View reviewed changes

Add more polyfills and expose globals

2bd9a05

youknowriad reviewed Oct 10, 2018

View reviewed changes

gziolo reviewed Oct 10, 2018

View reviewed changes

Copy vendors instead of building them

25dcd5e

youknowriad approved these changes Oct 10, 2018

View reviewed changes

Add missing packages and update the rest

c6f895c

gziolo reviewed Oct 11, 2018

View reviewed changes

gziolo approved these changes Oct 11, 2018

View reviewed changes

ntwb reviewed Oct 11, 2018

View reviewed changes

atimmer closed this Oct 12, 2018

atimmer deleted the add-packages-webpack-config branch October 12, 2018 09:19

Uh oh!

Conversation

atimmer commented Oct 9, 2018

Uh oh!

youknowriad left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

youknowriad commented Oct 9, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gziolo commented Oct 9, 2018

Uh oh!

gziolo commented Oct 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gziolo Oct 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

youknowriad left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gziolo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

gziolo commented Oct 9, 2018 •

edited

Loading

gziolo Oct 10, 2018 •

edited

Loading

youknowriad left a comment •

edited

Loading