scaffold-command
scaffold-command copied to clipboard
wp-cli
Webpack and ESNext option in block scaffold
Block scaffolding exists via #88 and I think the current default is a sensible default, but a lot of us will need modern tooling. @ahmadawais has already built what a ESNext + Webpack option would need here:
https://github.com/ahmadawais/Gutenberg-Boilerplate/tree/master/block/02-basic-esnext
I can imagine that as opinions develop in the community about how to build blocks, this is likely to be come a templating system for different block types and workflows. So I'd like to propose a --template option.
When this option is false, which would be its default, then the current behaviour would happen. I also propose that one template esnext-webpack be created, based on Ahmad's boilerplate, to act as a reference implementation and also because there is an immediate need for it.
I think to make this happen the following would need to be done:
- Add a
templateargument to command, and add a template loader. - Convert files to mustache syntax and place in templates directory
I've not looked at the differences between repos but there is also esnext examples in this repo: • https://github.com/WordPress/gutenberg-examples
@Shelob9 Adding support for modern tooling is generally a good idea.
However, in this case, we'll end up with something that is not usable out of the box, as the scaffolding cannot easily hook up the new custom block into whatever build system is being used.
Do you have an opinion on how to deal with this? Ideally, we'd like the scaffolding tool to always create something workable, to have the best possible UX.
...maybe the scaffold plugin would need an option to provide a basic webpack configuration for JS-heavy plugins... ?
we'd like the scaffolding tool to always create something workable, to have the best possible UX.
Why can't the scaffolding process end by running npm install && npm run build.
...maybe the scaffold plugin would need an option to provide a basic webpack configuration for JS-heavy plugins... ?
Yes. I built a plugin yesterday by using wp scaffold block twice and then manually converting them to ES6 blocks the way I'm proposing to automate. That meant I had two separate package.json and two separate build process.
That's a bad workflow.
The only reason I want to agree with you is to argue that blocks shouldn't be developed in plugins, they should be developed standalone and added to plugins via composer or npm. But...
I can imagine that as opinions develop in the community about how to build blocks, this is likely to be come a templating system for different block types and workflows.
Keep in mind WP-CLI's philosophy:
When functionality ends up in WP-CLI, it should be good enough to become the defacto solution to the problem.
If there isn't yet a clear winner, it doesn't yet make sense in WP-CLI.
@Shelob9 How would you feel about a JS/Node based CLI that does what you want done here. I already have a working copy and will be releasing it next month. 🚀
@danielbachhuber I'd love to contribute this to WPCLI if you folks decide to go that way. 💯
Really the webpack config should sit a level higher than the individual block directory. Not that it couldn't be added.
One quicker and possibly easy win towards a more ES6 approach could be to have a flag to add export default registerBlockType(... to the block JS file. This would let you easily import it into an existing entry point you may have already setup with webpack.
I know this doesn't address the webpack config out the box approach, just my 2 cents.
Block scaffolding exists via #88 and I think the current default is a sensible default, but a lot of us will need modern tooling. ahmadawais has already built what a ESNext + Webpack option would need here:
@Shelob9 - it was clearly stated in #88 that we want to have support for ESNext which enforces build step. As @ntwb mentioned there are more ESNext examples in https://github.com/WordPress/gutenberg-examples. All those examples use Webpack configuration. We didn't explore this setup so far as there are a few things to take into consideration as you can see from the comments above.
I can imagine that as opinions develop in the community about how to build blocks, this is likely to be come a templating system for different block types and workflows. So I'd like to propose a
--templateoption.
Totally agree that we need to offer more templates. It was discussed on GitHub or WordPress Slack before. The idea is to follow examples from the repository I mentioned above and what @youknowriad describes in his blog in the post One thousand and one way to extend Gutenberg today. I can see that there are at least 3 different types of templates that we could generate + ES5 vs ESNext variations:
- static
- dynamic with Editable
- server-side rendered with post meta
...maybe the
scaffold pluginwould need an option to provide a basic webpack configuration for JS-heavy plugins... ?
Really the webpack config should sit a level higher than the individual block directory. Not that it couldn't be added.
@schlessera, @zgordon - I tend to agree with both of you that it would be a reasonable default to add build script to the package.json that is already included with the scaffold plugin command. wp scaffold block was created in a way which allows to put multiple blocks under blocks subfolder of the single plugin. This proposal naturally fits the current structure. It doesn't mean we have to. I'm just explaining how it works at the moment, so we could refine it if we agree to do so.
When functionality ends up in WP-CLI, it should be good enough to become the defacto solution to the problem.
I have an idea that would satisfy this philosophy and would open a possibility to offer ES6 at the same time. There is Lebab project which is simply the opposite to what Babel does. In the most simple case, we could run Lebab on the existing block.js file and put the output in the src/index.js file, which would be a nicely formatted ES6 file which would be an entry point for the Webpack build. That way it would work out of the box with the existing ES5 file, but once npm run build would be fired by the plugin developer block.js would get replaced with the generated file. Let me know what do you think?
I'm concerned about the idea of adding an extra dependency to the project. I'd be a fan of adding an --es6 flag or something of that type. The idea is that ES6 is already the accepted next iteration of javascript and thus, at some point, we'd only need to drop Babel. Until we get to that point with the browser support, we could simply offer an escape hatch to the future which is where codebase will end up already. In that regard, we could do something like --es_stable --es_next --es_edgewith--es_stable` being the default so we can keep a comfortable dev experience for those wanting to try out the new features.
