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

Plugin: Adding a build process #282

Merged
merged 5 commits into from
Mar 16, 2017

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Mar 16, 2017

This includes:

  • Using yarn
  • Using babel ES-latest
  • Using Webpack
  • Using ESlint (extends Calypso's rules for now). Could we use prettier?
  • Using Sass and autoprefixer

This includes:

 - Using yarn
 - Using babel ES-latest
 - Using Webpack
 - Using ESlint (extends Calypso's rules for now)
 - Using Sass and auto-prefixer
@youknowriad youknowriad self-assigned this Mar 16, 2017
@youknowriad youknowriad requested review from mtias and aduth March 16, 2017 09:51
@youknowriad youknowriad changed the title Plugin: Adding a build process to the plugin Plugin: Adding a build process Mar 16, 2017

const config = module.exports = {
entry: {
app: './src/index.js'
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

@aduth
Copy link
Member

aduth commented Mar 16, 2017

For many of these items we should include a "Why?" and "Do we foresee this being a challenge being integrated into core?"

  • Yarn: Might be objectively good, but is another install when npm on its own works well enough
  • babel-latest: Probably fine on the specification line; may want to try to avoid unstable "staged" APIs (though object spread is awfully tempting). Concern here is education on new features.
  • Webpack: I see this being a simple enough transition from Browserify, but we should still decide what it offers that couldn't be achieved with existing tools?
  • ESLint: We may not need this in the plugin directory, per Add base ESLint and EditorConfig configurations #166 . There's an existing "WordPress" shared configuration that I've extended there with a few more specific (and to my knowledge non-conflicting) rules
  • prettier: I'd argue no, unless it can be configured per WordPress styles
  • Sass and autoprefixer: Already used in core, should be fine

"node": true
},
"parserOptions": {
"ecmaVersion": 3
Copy link
Member

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?

Copy link
Contributor Author

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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

De-indent.

"keywords": [
"WordPress",
"editor",
"prototype"
Copy link
Member

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__ ) );
Copy link
Member

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.

@youknowriad
Copy link
Contributor Author

youknowriad commented Mar 16, 2017

Yarn: Might be objectively good, but is another install when npm on its own works well enough

Yes, the advantages of yarn are locking properly and performance IMO.

may want to try to avoid unstable "staged" APIs (though object spread is awfully tempting.

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 :)

Prettier

I do agree, I think if it needs to be done, it should probably be a core first decision.

There's an existing "WordPress" shared configuration

I think the plugin directory should be self-sufficient (could be moved to its own repository), I don't mind duplicating the same .eslintrc.json from the root folder. I was not sure if the wordpress rules work well for ESnext, that's why I've used calypso's rules at first.

Consider the first commit of the PR as my own choices and I'm happy to update them to match the PR discussions :)

@aduth
Copy link
Member

aduth commented Mar 16, 2017

Yes, the advantages of yarn are locking properly and performance IMO.

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.

There's no "staged" API on "babel-latest".

Sorry, I was unclear. I understand this and am fine with 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 :)

Yeah, would be wise to find ourselves needing it before preemptively deciding it'll be useful.

@aduth
Copy link
Member

aduth commented Mar 16, 2017

I don't mind duplicating the same .eslintrc.json from the root folder. I was not sure if the wordpress rules work well for ESnext, that's why I've used calypso's rules at first.

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

@youknowriad
Copy link
Contributor Author

PR updated.

Should we git ignore the build folder and rely on the GitHub releases? any decision here @aduth

@aduth
Copy link
Member

aduth commented Mar 16, 2017

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.

@youknowriad
Copy link
Contributor Author

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__ ) );
Copy link
Member

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.

Copy link
Member

@aduth aduth left a 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 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants