-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Plugin: Adding a build process #282
Conversation
This includes: - Using yarn - Using babel ES-latest - Using Webpack - Using ESlint (extends Calypso's rules for now) - Using Sass and auto-prefixer
plugin/webpack.config.js
Outdated
|
||
const config = module.exports = { | ||
entry: { | ||
app: './src/index.js' |
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 was thinking we should call this folder editor
, and it would more closely represent what we may be bringing into core.
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.
What about the distinction src
/build
? Do you think we should use editor
as a parent directory or it's ok to keep build
as is?
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 may put the build in the root of the plugin.
For many of these items we should include a "Why?" and "Do we foresee this being a challenge being integrated into core?"
|
plugin/.eslintrc.json
Outdated
"node": true | ||
}, | ||
"parserOptions": { | ||
"ecmaVersion": 3 |
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.
Likely ignored with babel-eslint
parser override. Do we need to use babel-eslint
or is the default parser sufficient?
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.
From the docs:
You only need to use babel-eslint if you are using types (Flow) or experimental features not supported in ESLint itself yet
We may need it, if we decide to add object-spread, but we could drop it for now.
.gutenberg__editor { | ||
max-width: 700px; | ||
margin: 0 auto; | ||
img { |
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.
De-indent.
plugin/package.json
Outdated
"keywords": [ | ||
"WordPress", | ||
"editor", | ||
"prototype" |
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.
Not a prototype 😄
@@ -21,7 +21,7 @@ function gutenberg_menu() { | |||
|
|||
function gutenberg_scripts_and_styles( $hook ) { | |||
if ( $hook === 'toplevel_page_gutenberg' ) { | |||
wp_enqueue_style( 'gutenberg_css', plugins_url( 'style.css', __FILE__ ) ); |
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.
Curious if extract-text-webpack-plugin
(what we'd eventually want to use to pull out CSS) can be integrated easily into a development configuration.
Yes, the advantages of yarn are locking properly and performance IMO.
There's no "staged" API on "babel-latest". I was also tempted to add "object spread" but I thought it could be done later if we have a lot of Object.assign :)
I do agree, I think if it needs to be done, it should probably be a core first decision.
I think the Consider the first commit of the PR as my own choices and I'm happy to update them to match the PR discussions :) |
My own opinion is that Yarn will follow the same story of HHVM vs. PHP, where the project motivates upstream improvements. PHP7 made HHVM irrelevant for many, and in the same way I hope npm will eventually adopt many of the ideas of Yarn. It's also one fewer prerequisites for getting started, which should always be a chief concern for helping contributors become involved.
Sorry, I was unclear. I understand this and am fine with
Yeah, would be wise to find ourselves needing it before preemptively deciding it'll be useful. |
You raise a good point that many of those rules may not be applicable, or could be improved with ES2015+ specific additions. I'd still rather at least enumerate them explicitly than extend Calypso's ruleset (which includes a few style variations from WordPress' own). |
PR updated. Should we git ignore the build folder and rely on the GitHub releases? any decision here @aduth |
My view is yes, to leave it out of the repo. While this will make the plugin unusable out of the box on master, it's more likely we'll want previews on tagged releases anyways. We always have the option to add it later if we decide it's not working well. |
the build is ignored now :) Can I have a 👍 to merge this or are there any other things we could discuss. BTW, we could always iterate on these later :) |
@@ -21,7 +21,7 @@ function gutenberg_menu() { | |||
|
|||
function gutenberg_scripts_and_styles( $hook ) { | |||
if ( $hook === 'toplevel_page_gutenberg' ) { | |||
wp_enqueue_style( 'gutenberg_css', plugins_url( 'style.css', __FILE__ ) ); | |||
wp_enqueue_script( 'gutenberg_js', plugins_url( 'build/app.js', __FILE__ ) ); |
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.
This 404's because it's loading from the Gutenberg root. Should be plugin/build/app.js
.
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.
While my previous remark is true, it also speaks to issues of using repository directly as plugin with plugin code living in a subdirectory. I think we'll need to move plugin/index.php
to the top-level directory, or at least symlink it. We should do that in a follow-up PR and merge this as is 👍
This includes: - Using babel ES-latest - Using Webpack - Using ESlint - Using Sass and auto-prefixer
This includes: