-
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
Build: Add building/watching support to Gutenberg packages #6708
Conversation
} | ||
} ); | ||
|
||
setInterval( () => { |
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.
Might be worth considering replacing this with a debounced function that's triggered in rebuild
. Not really a major thing though.
fs.watch( path.resolve( p, 'src' ), { recursive: true }, ( event, filename ) => { | ||
const filePath = path.resolve( srcDir, filename ); | ||
|
||
if ( ( event === 'change' || event === 'rename' ) && exists( filePath ) ) { |
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.
According to https://nodejs.org/docs/latest/api/fs.html#fs_fs_watch_filename_options_listener change
and rename
are the only two possible options for event this can probably be shortened to exists( filePath )
.
7faa1be
to
751fdb3
Compare
I added a few tweaks to this PR based on what I discovered while testing locally. It works great for me. Some open questions:
Tested so far:
Tested manually in the browser. I also want to make some more in-depth analysis for bundles which we output after those changes got introduced. |
@@ -139,7 +139,7 @@ | |||
"fixtures:generate": "npm run fixtures:server-registered && cross-env GENERATE_MISSING_FIXTURES=y npm run test-unit", | |||
"fixtures:regenerate": "npm run fixtures:clean && npm run fixtures:generate", | |||
"package-plugin": "./bin/build-plugin-zip.sh", | |||
"postinstall": "lerna bootstrap --hoist", | |||
"postinstall": "lerna bootstrap --hoist && npm run build: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.
We might need it later when we start referencing internal packages. This was the case for WordPress/packages
at least.
/** | ||
* Babel Configuration | ||
*/ | ||
const babelDefaultConfig = require( '@wordpress/babel-preset-default' ); |
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 should load setup from package.json
- we use some overrides.
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 should use a separate config here. The root config could contain things we don't want here.
For example: generating the "messages.pot" file should not happen here but should happen when webpack performs the building (it's not something we want to include per module).
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.
Yes, this is also what I figured out when trying to update this config yesterday.
I published new version of Babel preset to include missing async generator functions plugin.
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 wondering something though about the "messages.pot" generation :). babel may change variable names and function names and this could cause the make-pot to fail and not find the right strings. So in the end it might be better to include it here?
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.
#6893 will cover the support for async generator functions.
Comparison of Webpack generated assetsBefore
After
|
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 didn't discover any regressions. Build files generated by Webpack look almost identical to what we had before. Let's proceed and see how it works.
I think we will have to ask people to run npm i
on their repositories.
I'm personally still concerned about the messages extraction. What will happen when some messages are in packages and others are still in the current modules? how do we make the extraction work? cc @aduth |
I've not really kept up with how the packages integration has progressed. I'm also not sure whether we'd want packages themselves to provide any pre-extracted strings data, or if we just assume they call As for where this stands currently, have you tried generating the POT file to see if it includes neither/either/both of packages and non-packages strings? Since our Webpack's |
Ok did some tests and it should work because in the |
This PR builds on top of #6658 and adds building support to the Gutenberg packages.
The build/watch scripts added in the PR are copied and adapter from Facebook Jest and WordPress packages scripts.
The idea is to consider these packages as real external modules. Building happens in two steps, the build script generates the
build
andbuild-module
transpiled files and webpack uses these built files to generate its bundle with the library support (global variable).This means for dev environments, we need to watch changes on each file individually, build this file which will then trigger the webpack watching to the compiled files.