JavaScript chat summary, June 25th + July 2nd, 2019

Below is a summary of the discussion from the JavaScript chat of the last two weeks (agenda June 25thSlack Transcript June 25th, agenda July 2ndSlack Transcript July 2nd)

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

Agenda: E2E Test infrastructure for Core

Slack Conversation June 25th

A ticket was created by @youknowriad which seeks to incorporate Gutenberg’s end-to-end test setup into WordPress core: The patch has been reviewed by multiple members of the Core JS team and was eventually committed. @youknowriad wrote a devnote here:

Agenda: E2E Tests – next steps

Slack Conversation July 2nd

With the e2e framework now in core, we can start adding testcases. A few good next steps were raised:

  • Encouraging people to write tests, anytime we notice a regression or an important feature. Some coordination would probably help. Who could help lead/organize it?
  • Try to run the Gutenberg e2e tests (maybe not all of them) in Core’s CI as well. This would allow upgrading the npm packages from Gutenberg in Core with more confidence.
  • Extending the framework to be able to run tests across PHP versions could definitely be helpful for smoke testing pages, checking there are no warnings, etc.
  • Improving the documentation with regard to e2e test would also be valuable.

These points could best be raised in Devchat as well, as they transcend the realm of Core JS.

Agenda: Build all Core JS with WebPack

Slack Conversation

A new patch was uploaded by @herregroen to build all core JavaScript with Webpack: Building all JS in core with WebPack means we can have a single consistent build process for all JS, rather than having different build tools for Gutenberg and the media library versus everything else. It also allows us to start reusing WordPress packages in the JavaScript that is already present in core. Some more review and testing is needed.

Open Floor: Request for feedback

Slack Conversation

There is some exploration going on around possible solutions for interpolating React elements in strings in this Gutenberg issue: @nerrad has requested some feedback to some recent considerations he’d proposed in that issue. Input is welcome!

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

JavaScript chat summary, May 14th, 2019

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

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

Agenda: React Hooks for Data

Slack Conversation

We discussed an issue to introduce a useSelect React hook to the @wordpress/data package. The discussion focused on determining what the best API would be and a concern was raised to investigate the potential performance impact. We agreed it would be best to have a single useSelect function which allows to pass in a mapping callback for more complex conditional type use-cases involving multiple selectors/stores. We could create utility functions for simple cases.

Open floor: Node compatibility

The version of node-sass we use isn’t compatible with Node 12.x. A PR to update node-sass to a compatible version is now merged.

#core-js, #corejs, #javascript, #js

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:

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

Javascript Chat Summary – October 23, 2018

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: Should wp.hooks support the special all hook?

Slack Conversation

In Gutenberg#8602 it is raised if we should add support for an all action in wp.hooks in order to match feature parity with the current PHP hooks system in WordPress core. While there were no real objections raised in the chat, pretty much everyone present agreed with this comment:

If it is primarily intended for debugging, then it might be worth exploring optimizations to avoid any impact in typical usage, e.g. monkey-patching runHooks when an all hook is added.



  • No interest was expressed in the issue. If anyone wants to take it on, there wouldn’t be any objections either.

Agenda: Ways to optimize the package updating process

Slack Conversation

The process for updating packages needs to be optimized further. Right now any fix on a package has to follows the cumbersome flow of Gutenberg PR -> lerna release -> core ticket -> update package.json -> commit. We need to make this smoother.

This problem would probably not exist once everything is merged into a single monorepo hosted on git. But that doesn’t seem feasible just yet. Could we maybe mimic the advantage of having a monorepo a bit by getting more tooling into WordPress core and build straight from Github source? That would at least decouple publication of packages from being able to consume their changes in WordPress core development. 

It was raised by @gziolo that installing Gutenberg straight from Github with npm is not an option because Gutenberg consumes local packages which can’t be resolved by npm. The solution proposed is to take a similar approach to how Gutenberg packages are updated for Drupal.

This is done with an install script that simply clones Gutenberg into node_modules and builds the scripts in Gutenberg itself. While not a very elegant solution, this could work and drastically improve the process of keeping the packages updated.


  • @atimmer will work on a proof of concept.

Open floor: JS i18n

Slack Conversation

Good progress is being made on JavaScript language packs. 🎉 @herregroen is working together closely with @nerrad, @swissspidy and @ocean90 to land this. There seems to be a great deal of consensus and the work is nearing completion.

#corejs, #javascript

JavaScript Chat Summary – October 9th

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.

Preparing for WordPress 5.0

Action items

Annotations API in Gutenberg

  • The foundation work will be shipped in 4.0: The RichText package and the RichText structure.
  • A custom format API will be added. Likely for 4.1.
  • The annotations API should be built on top of this custom format API.

Action items

  • Continue the work on the custom format API targeted for 4.1: @iseulde
  • Coordinate with the Annotations API PR: @atimmer @iseulde

Generic Data Store API

The Data Module of Gutenberg is composed of two parts:

  • The Producer API: Registering stores, selectors, actions.
  • The Consumer API: Consuming selectors and actions in components and other scripts.

@coderkevin proposed to make the producer API less opinionated allowing custom stores implementations to leverage advanced use-cases for big applications/plugins like Calypso or WooCommerce while ensuring backward compatibility for the current implementation.

No blocker was raised on the Core side and the work should continue on the proposed PR.

Action items

#corejs, #javascript