Skip to content
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

Webpack and ESNext option in block scaffold #106

Open
Shelob9 opened this issue Dec 16, 2017 · 11 comments

Comments

@Shelob9
Copy link
Contributor

@Shelob9 Shelob9 commented Dec 16, 2017

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 template argument to command, and add a template loader.
  • Convert files to mustache syntax and place in templates directory
@Shelob9 Shelob9 changed the title Wepaback and ESNext opiton in block shaffold Wepaback and ESNext option in block scaffold Dec 16, 2017
@Shelob9 Shelob9 changed the title Wepaback and ESNext option in block scaffold Wepback and ESNext option in block scaffold Dec 16, 2017
@youknowriad

This comment has been minimized.

Copy link

@youknowriad youknowriad commented Dec 16, 2017

cc @gziolo

@ntwb

This comment has been minimized.

Copy link
Contributor

@ntwb ntwb commented Dec 16, 2017

I've not looked at the differences between repos but there is also esnext examples in this repo:
https://github.com/WordPress/gutenberg-examples

@schlessera

This comment has been minimized.

Copy link
Member

@schlessera schlessera commented Dec 17, 2017

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

@schlessera

This comment has been minimized.

Copy link
Member

@schlessera schlessera commented Dec 17, 2017

...maybe the scaffold plugin would need an option to provide a basic webpack configuration for JS-heavy plugins... ?

@Shelob9

This comment has been minimized.

Copy link
Contributor Author

@Shelob9 Shelob9 commented Dec 17, 2017

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

@danielbachhuber

This comment has been minimized.

Copy link
Member

@danielbachhuber danielbachhuber commented Dec 18, 2017

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.

@ahmadawais

This comment has been minimized.

Copy link

@ahmadawais ahmadawais commented Dec 18, 2017

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

@zgordon

This comment has been minimized.

Copy link

@zgordon zgordon commented Dec 18, 2017

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.

@gziolo

This comment has been minimized.

Copy link
Contributor

@gziolo gziolo commented Dec 18, 2017

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

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
@gziolo

This comment has been minimized.

Copy link
Contributor

@gziolo gziolo commented Dec 18, 2017

...maybe the scaffold plugin would 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?

@motleydev

This comment has been minimized.

Copy link

@motleydev motleydev commented Feb 1, 2018

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.

@schlessera schlessera changed the title Wepback and ESNext option in block scaffold Webpack and ESNext option in block scaffold Nov 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
9 participants
You can’t perform that action at this time.