JavaScript chat summary, April 16th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Closing the Loop: TypeScript

Slack Conversation | Previous Conversation

Question: What decision do we arrive at based on the previous discussion and comments?

Context: It had been an agenda topic for a meeting last month to consider whether to maintain and accept pull requests proposing to include TypeScript definitions in the project. As previously discussed, it was generally agreed upon to not maintain these in the project. Additional time was allotted to allow for asynchronous feedback. Since then, the topic had not been revisited.

Decision: TypeScript definitions will not be maintained in the Gutenberg repository.

Follow-up: In an effort to support those who may find benefit in these definitions, we should at least consider documenting third-party resources.

Action items:

  • Explain decision and close the related pull request. (Owner: @aduth)
  • Open a new documentation issue to outline the desired resources, and invite those from the affected pull request to provide feedback as to what specific information would most benefit interested developers and require the least ongoing maintenance. (Owner: @aduth)

Future of Block Registration

Slack Conversation | Previous Conversation

An update was shared on a proposed Webpack plugin discussed during the previous week’s meeting, which would help provide automation for the tedious and error-prone task of manually maintaining script dependencies. (Note: The pull request has since been merged)

Subsequent discussion was two-fold:

  • Could this plugin be used to help solve the unanswered question around asset management for the ongoing Blocks Registration RFC discussion? And if so, what would that look like?
    • There was some consideration about whether the manifest output by this tool, when used in combination with an explicit or implicit entry point to a block, could be sufficient to derive all necessary information to register and load a script and its dependencies.
  • Would this or its impact on the Blocks Registration RFC impact (for better or worse) an existing issue with load order of scripts and the challenge it poses to plugins who seek to extend blocks?
    • It was not considered to be directly related. However, there was some follow-up discussion about the use of filters generally, and whether the Blocks Registration RFC could have an impact in considering the registered block type to be aggregate of a series of patches (merging the block manifest, the client-side definition, and any third-party modifications).
    • Action Item: Continue discussion on the associated issue.

#javascript

JavaScript chat summary, April 9th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Administrative

@aduth requested an update to the meeting time displayed in https://make.wordpress.org/core/ — the time being shown was wrong and it should be corrected to be one hour later.
@sergeybiryukov performed the update.

Agenda: Feature: Add webpack plugin to externalize and extract script dependencies

A pull request was proposed to implement a new module to help automate some of the processes around assigning webpack externals.

@aduth provided some context:

A problem we have today is we have the package.json each package which lists these, then they need to be duplicated again into lib/package-dependencies.php, which sometimes does not occur

The pull request was generally well received, people participating in the meeting noted that it may be a step to eliminate the need for maintaining dependencies in PHP for plugin developers utilizing webpack or wp-scripts build workflow.

@aduth referred that the broader problem of from just a JavaScript file figuring out the dependencies may not be possible to solve.
If someone reading this has any idea that would work in the majority of cases feel free to comment.

@youknowriad referred he would prefer to have the mechanism implemented as a babel plugin instead of a webpack plugin as babel is more “universal” tool to read JS and transform it, and would allow the mechanism to work in plugins using other bundle systems like Parcel. But reinforced that he is not against a first version using a webpack plugin.

Agenda: Filterable translation functions

@swissspidy proposed a pull request that makes all gettext functions from the i18n package filterable.

There was some consensus that although the filters may not have a big overhead during a gettext function call, the function is a hot path and may be called many times during the application usage.

The discussion went forward and people analyzed some tradeoffs of the following potential alternatives:

  • Apply the filters on the server.
  • Add a labels property to the editor setting that developers may change.
  • Provide developers a simple way to extend an i18n file with another file containing their customizations.

Ultimately it seemed people were not able to decide on a solution because there is a lack of knowledge of the high level need a plugin wanting to use a gettext filter may have.

@nerrad suggested the following action item:

experiment with actual benchmarking metrics for the filter approach using concrete examples

@swissspidy volunteered to find some concrete examples/use cases.

If anyone has some concrete examples please provide them as it would allow to decide the best path forward and would allow to have real-world measures of the performance.

#javascript

JavaScript chat summary, April 2nd, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Custom ESLint Rules

  • Current ESLint plugin enforces rules like “dependency group”, and “valid-sprintf” which are quite specific to Gutenberg / WordPress.
  • These rules are to be removed and recommended ESLints rules to be further discussed and enhanced.

Update to MediaElement.js

  • With recent browser changes, Vimeo videos will no longer autoplay in chrome. An update to MediaElement.js fixes the various issues.
  • MediaElement.js library to be updated and backported to previous WP releases, follow trac ticket for further info.

Packages Versioning

  • Current contribution guidelines for packages recommend that the person proposing a change decide the version bump based on the type of their change.
  • There have been few discussions in pull requests which indicates that the version should not be proposed as part of individual changes, rather decided at the time of publishing.
  • Contribution guidelines for packages changelog to be updated to recommend adding changes as “unreleased” or “master”.
  • Some discussions around experimenting with the automated changelog creation for long term solution.

#meeting-notes, #core-js, #javascript

#javascript

JavaScript chat summary, March 26th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Building JavaScript

Slack Conversation

A post was published on the core Make blog titled Building JavaScript. It explains how to set up an ESNext development environment using the new WordPress scripts package. This provides an easy and standard method for building blocks and JavaScript heavy plugins.

The discussion continued towards a potential followup task: to offer a scaffolding package that would help to create your first block. This could then in turn be utilized by the wp scaffold command in WP CLI, to allow scaffolding blocks directly with WP CLI. The discussion continues on Github here: https://github.com/WordPress/gutenberg/issues/10629.

Agenda: Coding Guidelines

Slack Conversation

Coding guideline changes have been proposed for CSS naming and Experimental / Unstable JS API’s in Gutenberg. Feedback is welcome!

Agenda: Gutenberg Playground

Slack Conversation

A standalone Gutenberg playground environment has been merged. As we’re expanding the usage of Gutenberg outside of edit-post and also talking about cross-CMS usage and external usage (in the broad sense), we need a way to run the block editor in a context independent from WordPress Admin.

The playground allows us to test Gutenberg as a standalone editor. For example, we can use it to test that our components don’t rely on WP Admin styles to be present, that core blocks can be used without necessarily requiring a post object.

This is only a first step. The playground could evolve to contain examples of reusable components, and it could also serve as a contributor-tool to help developers discover API’s.

#core-js, #corejs, #javascript, #meeting-notes

Building JavaScript

The Gutenberg Handbook shows JavaScript examples in two syntaxes: ES5 and ESNext. These are version names for the JavaScript language standard definitions. You may also see elsewhere the names ES6, or ECMAScript 2015 mentioned. See the ECMAScript Wikipedia article for all the details.

ES5 code is compatible with WordPress’s minimum target for browser support. It can run straight in your browser and does not require an additional build step. In many cases, it will be perfectly fine to follow the same approach to start experimenting with your plugin or theme quickly. As soon as your codebase grows to hundreds of lines, it might be a good idea to take advantage of all the great JavaScript features included in ESNext syntax.

With the release of Gutenberg 5.3, the @wordpress/scripts package was updated to include webpack and Babel configurations. The update makes setting up an ESNext development environment much easier for building blocks and creates a standard method for developers to set up their plugin.

The documentation in the JavaScript tutorial and the ESNext examples in the gutenberg-examples repository are both updated to include the new process.

Here is a quick overview of how to set up an environment. First, you need to install @wordpress/scripts package:

npm install --save-dev @wordpress/scripts

You can then update the scripts section of your package.json to include:

"scripts": {
    "start": "wp-scripts start",
    "build": "wp-scripts build"
}

No webpack config (e.g., webpack.config.js) or Babel config (e.g., .babelrc) is needed.

The scripts expect the source file to be found at src/index.js and will output the build to build/index.js. So if you are migrating an existing plugin, you will need to move your source and enqueueing to these new locations.

With the setup in place, the standard workflow is:

  • Install dependencies: npm install
  • Start development builds: npm start
  • Develop. Test. Repeat.
  • Create production build: npm run build

In general, the package should be used with the set of recommended config files. While it is possible to override every single config file provided, if you have to, it means that your use case is more complicated than anticipated. We’d love hearing about it as we’d like to iterate on the current setup and offer more flexibility in the future. At the moment, our recommendation would be to use the underlying tools (webpack, Babel) directly.

See the JavaScript Build Setup documentation for a full explanation and walk through, and see the scripts package documentation for all the details.

Props to @gziolo and @nosolosw for their efforts.

#core-editor, #core-js, #javascript

Javascript Chat Summary – March 19, 2019

Below is a of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Reconciling WordPress and Gutenberg Script Handles

Context | Previous Effort | Slack

Some points there seemed to be consensus on:

  • As needed, existing scripts in WP core will be pulled into the GB repository, exposed as their own package, and then re-registered for use in core.
  • Old handles will still be present for back-compat, but redirect to new handles.

Initial effort regarding this will happen for:

  • shortcode package: https://core.trac.wordpress.org/ticket/44987
  • a11y package: https://core.trac.wordpress.org/ticket/45066

Agenda: How should uncaught errors be handled

Context | Slack

There was much discussion on not only the specific issue (see context) that triggered this agenda but also how this might be generalized. In conclusion, there was some consensus to explore something along the lines of [this solution](https://gist.github.com/aduth/f464f2d549a80716127a7e0d575b102f) in concert with implementing error boundaries in withSelect to see how they interact and work. So short-term focus will be on fixing the immediate issue with errors in subscriber listeners.

Further discussion effort on this will be done in the pull request @aduth will own this issue (in collaboration with others who help).

Agenda: Reusable Scripts

Context: here and here | Slack

This is work towards making the Javascript build setup for plugins much more simplified.

We reached the point where we exposed every tool Gutenberg uses adjusted for external plugins development

@gziolo

Related packages will be published soon.

Action Items:

  • update repository (once package is updated on npm) (@gziolo)
  • dev note about the package linking to the docs and repository (@gziolo)

#core-js, #javascript

JavaScript Chat Summary, March 12th, 2019

Below is a summary of this week’s JavaScript chat (agendaSlack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Daylight savings time

Slack Conversation

@aduth proposed to not move the meeting time this instance, because for some people having the meeting an hour later means they can attend. If you have any feedback on this proposal, please leave a comment.

Default webpack configuration

Slack conversation

A default webpack configuration pull request has been merged to wp-scripts. So plugin authors can now do wp-scripts build and that will build their JavaScript into a bundle for the browser.

There was a brief discussion on whether or not the build command should accept a custom webpack configuration. For now this will stay possible. In the longer term the default configuration should be good enough for a lot of users and the Gutenberg webpack config should align with the default config as much as possible.

Pull request for typescript definitions

Slack conversation

The Gutenberg repository received a pull request with TypeScript definitions. This raised the broader question whether these pull requests should be accepted, because these definitions also need to be maintained.

In the chat the consensus was that it is only worth merging these kinds of PRs if the maintainability burden is very low. Given that is not the case it is probably better to not merge the given PR.

This will be decided on next week, please comment here with your ideas on this.

Removing grunt dependency from grunt-patch-wordpress

Slack conversation

@jorbin wants to make the grunt-patch-wordpress tool a general command-line utility that runs without a grunt dependency. Everyone agreed that this is a good idea. The new package will be located inside the monorepo like all other JavaScript packages.

#core-js, #javascript

JavaScript Chat Summary, March 5th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

repository.directory

Slack Conversation

Following up from the previous week’s agenda item about the newrepository.directory field in package.json file. @greatislander was successful in having his enhancement merged into the upstream npm-package-json-lint package. He also followed up with a pull request to use it in Gutenberg.

Npm package release process

Slack Conversation

Right now the timeline for publishing npm packages is strictly tied to WordPress releases. Moving forward, the idea is they would be published more frequently as proposed by @youknowriad in this pull request. It is expected to start using the revised workflow soon after Gutenberg 5.2 release is out which is planned for Wednesday.

Docgen

Slack Conversation

@nosolosw merged a pull request with the first iteration of the @wordpress/docgen package, which will be used to auto-generate public API documentation from JSDoc comments. The idea is that the npm run docs:build command will re-generate the package’s README when something changes in the JSDoc comments. There is a master issue opened where follow-up tasks will be tracked. It’s expected to have a massive number of pull requests created which add public API documentation to most of the existing packages.

#core-js, #javascript

JavaScript Chat Summary, February 26th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Progress Updates

Slack Conversation

@greatislander finished adding repository.directory fields for each published package, and opened an upstream pull request to the npm-package-json-lint project so that can better enforce this for new packages introduced in the future.

@gziolo and @nosolosw completed work on extracting a reusable Webpack configuration which can be used by developers (e.g. plugin authors) to easily adopt a Gutenberg build workflow into their own projects. @nosolosw mentioned that work continues to use this configuration as the default when running wp scripts build if no explicit configuration is provided.

Package Releases Feedback and Enhancements

Slack Conversation

@youknowriad shared a summary of the current workflow for publishing npm packages, the shortcomings therein, and proposed a revision to the workflow which better supports more regular publishing accommodating WordPress minor releases.

I propose we update our workflow to the following: (assuming the version number of the packages are major.minor.patch)
– Rename the current g-minor branch (the branch from which the npm releases are made) to wp/trunk
– Every time a new plugin version is released (using our current plugin release workflow), merge this version into wp/trunk, do an npm package release by bumping at least the « minor » version number (or major but not patch)
– Every time, the WordPress SVN trunk is branched (to create WordPress 5.1, WordPess 5.2… branches) — this happens in general when the WordPress major RC version is created —, create a corresponding wp/5.1, wp/5.2 etc… in Github based on wp/trunk.
– This wp/x.x branch will serve to release package releases used in Minor and security versions of WordPress. All package releases happening from these branches will bump only the patch version number of the package.


Special cases:
– Sometimes WordPress trunk is closed (in general it last 2 to 3 weeks) between beta and RC. During this period, we’ll have a Gutenberg plugin release that is not going to be released as npm packages directly until WordPress trunk is open again.
– For previous WordPress versions that contain packages (5.0 and 5.1) we didn’t have enough room for package version upgrades for security and patch versions that might be needed in the future. For these particular cases, we’ll use the « build metadata » version modifier supported by npm. Example 1.2.4+sec.1

Discussion followed this proposal, clarifying details of the revised workflow. There was general consensus that the proposal was agreeable.

As a next step, @youknowriad plans to open a pull request proposing revisions to the current release workflow document.

Open Floor

Slack Conversation

@greatislander requested an update on when the jest-puppeteer-axe package would be made broadly available, as its unavailability is a blocker to the accessibility team being able to implement front-end tests for themes. In mind of the above release workflow proposal revisions, it was suggested that it could be published this week if the workflow changes are adopted.

#core-js, #javascript

JavaScript chat summary, February 19th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: NPM Mono-Repo Subdirectory Declaration

https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md

@adamsilverstein quoted @aduth‘s note that we should consider implementing the npm monorepo declaration in the WordPress npm packages.

@aduth added that implementing this declaration would be a straightforward task that would help make npm more “aware” of where to find the specific source for a package in a mono-repository, hopefully improving links.

The idea was well received.

@aduth has created issues related to this task:

Feel free to share your thoughts and provide feedback related to this subject in the issues.

Agenda: Feature Flags

https://github.com/WordPress/gutenberg/pull/13324

Feature flags were merged in the Gutenberg repository. Quoting @gziolo:

feature flags in Gutenberg, it’s very simple approach which will allow us to enable new features only for the plugin while keep it completely removed from WordPress core using dead code elimination.

We went into more detail of what feature flags are and what they allow.

@atimmer noted that most commonly feature flags allow to enable or disable specific features while Gutenberg feature flags apply to a whole set of features e.g.: “phase 2 features”.

@aduth referred that the reason behind this decision may be related at least partly to the objective of simplifying dead code removal.
More information can be found at https://github.com/WordPress/gutenberg/pull/13324.

@adamsilverstein shared that he wants to introduce a feature in the hooks package whose code should only be included when the SCRIPT_DEBUG flag is set. Any feedback to this is welcome and can be provided in https://github.com/WordPress/gutenberg/pull/12038.

During the discussions, it was referred that, although dead code removal is a common and used by famous libraries like React, there are no good resource/references available online to help developers understand how dead code removal works.
If you know any good resource feel free to share the link in the comments or the core-js channel.

Agenda: Build support for wordpress/scripts

Relevant PR’s:

According to @gziolo both PR’s are almost ready, but they need additional testing given the complexity of running the scripts with default configuration in various external projects.

@adamsilverstein noted that webpack setup is a significant barrier to entry for new developers and the more we can improve our tools the better.

@gziolo referred that a tutorial was already created and it will be simplified after latest changes are published.

Open floor

@nerrad referred that he would like to use the new version of React, more specifically React hooks, and asked when a React upgrade should be considered and when a WordPress release will contain the next version of React.

Answering to @nerrad, @aduth noted that upgrading React should be a non-issue although we may need some scrutiny on what is exposed. Regarding the WordPress releases, @aduth expects that anything merged to Gutenberg repository between now and mid-March should be part of the WordPress 5.2 release, but this specific subject will be clarified during the next #core-editor meeting https://make.wordpress.org/core/2019/02/19/editor-chat-agenda-february-20th/.

@nosolosw announced that in the past days the first auto-generated API documentation was merged to the Gutenberg repository: https://github.com/WordPress/gutenberg/pull/13856.
The tool that autogenerated the documentation is proposed in https://github.com/WordPress/gutenberg/pull/13329.
The next package/component that will be used as a testbed for the tool is not yet decided and every suggestion is welcome.

#core-js, #javascript, #meeting-notes