Packages: Add common utilities to WP.com block editor package

[mmtr]

Changes proposed in this Pull Request

Add a new folder for all the common utilities we need to run in both block editor environments (Gutenframe and WP Admin).

So far, these utilities are the rich text extensions to add the missing formats in Core (justify, underline) and the "Switch to Classic" button on the "More tools" menu.

The logic of these utilities were previously maintained on the gutenberg-wpcom.js file, so the files added to the common/ folder on this PR contain the same code but using ES2015+ syntax.

The documentation has also changed in order to make more obvious there are 2 environments we need to support. Note that I also grouped the previous scripts in a calypso/ folder to reflect that the utilities inside this folder will be run only in a iframed block editor context.

Given that this is adding a new entry file to the build script, I decided to split the bundle script into 3 smaller build scripts (one for each entry file), so we don't have a very long script command. The build scripts runs now all the smaller build scripts in parallel (using npm-run-all) and requires an explicit output path (reason why the clean script is not needed anymore).

Testing instructions

Check D26970-code

[matticbot]

Test live: https://calypso.live/?branch=update/wpcom-block-editor-common-utilities

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[kwight]

Might as well remove this; it's not present, and not anticipated in the near future.

[kwight]

Awesome work ❤️

I did notice the minified scripts are missing from a manual build, and comparing the artifacts build versus the manual build shows a lot of differences (eval seems like not a great thing?) – should they be aligned, and which would be preferable?

The documentation has also changed in order to make more obvious there are 2 environments we need to support. Note that I also grouped the previous scripts in a calypso/ folder to reflect that the utilities inside this folder will be run only in a iframed block editor context.

This is magnificent, thank you! 🎉

[dmsnell]

Looks like some good improvements here. I don't see any reason to block merging this.

Thanks @mmtr for updating this code. Those scripts are starting to make me long for our Makefile again… 😉

[simison]

If this gets too funky at some point, you could also create a simple Webpack config for this package that inherits and extends the one from Calypso-build, similarly to client/notifications/.

[mmtr]

I did notice the minified scripts are missing from a manual build, and comparing the artifacts build versus the manual build shows a lot of differences (eval seems like not a great thing?) – should they be aligned, and which would be preferable?

Yeah, this is normal since the commands used in the manual build are different from the automatic CircleCi build.

The CircleCI job executes two commands:

1. Build for the unminified scripts.

SOURCEMAP='inline-cheap-source-map' npx lerna run build --scope='@automattic/wpcom-block-editor' -- -- --output-path=$CIRCLE_ARTIFACTS/wpcom-block-editor

SOURCEMAP='inline-cheap-source-map' is used for generating a more readable build file in order to ensure compliance with the plugin guidelines.

2. Build for the minified scripts.

NODE_ENV=production npx lerna run build --scope='@automattic/wpcom-block-editor' -- -- --output-path=$CIRCLE_ARTIFACTS/wpcom-block-editor --output-filename=[name].min.js

NODE_ENV=production is used for enabling the minification.

---

I was thinking in wrapping these 2 commands in a single npm script that replaces the current build script, so both builds (manual and automatic) will generate the same dist. But I didn't see any other script in Calypso that defines a NODE_ENV env var, which is the main reason why I didn't go for it, since this would prevent to skip the minification if we really don't want it.

Probably in this case we want consistency rather than flexibility, so I'm going to commit a change grouping the 2 commands so npx lerna run build --scope='@automattic/wpcom-block-editor' will generate both the unminified and minified bundles.

Edit: changed in a12f1c8

@sirreal @simison @ockham let me know if should take another approach here.

[sirreal]

A peculiarity of monorepo: devDependencies in non-root packages don't really mean anything. It's preferable to never include them, any devDependencies must be in the root package.

[mmtr]

Wouldn't that cause a conflict with the import/no-extraneous-dependencies ESLint rule?

[simison]

Might be. :-) It's not ideal — all I know it's causing trouble. See e.g.: #32383

cc @blowery