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

Introducing the WordPress e2e tests

The purpose of e2e (end to end) testing is to simulate the real user scenario and validate the different flows. In concrete, running an e2e test involves setting up a production-like environment, opening a browser and interacting with the application as it was a real user manipulating the interface. This is one of the best testing methodologies to avoid regressions.

Gutenberg has been successfully using this kind of tests for some time now. Reusable packages to setup and run e2e tests have been built in the repository. Starting today, this setup was brought into WordPress and included in our CI pipeline.

Local Environment

The e2e tests require a production-like environment to run. The current setup relies on Docker to provide a built-in environment.

You can run the environment locally on your own WordPress Core clone.

First, make sure you have Docker installed (instructions on this link).

Then, you should be able to run the environment by running these commands on your own WordPress repository clone.

npm install
npm run env:start

This command will make sure you have the right node/npm versions installed, triggers docker containers for your web and mysql servers and installs WordPress using the build folder.

You can also reset the environment with a testing website using:

npm run env:reset-site

You should be able to access your environment on http://localhost:8889. The default username is admin and the password is password.

Running the e2e tests

Once your environment ready, you can launch the e2e tests suite by running:

npm run test:e2e

This will run the test suite using a headless browser. For debugging purpose, you might want to follow the test visually. You can do so by running the tests in an interactive mode.

npm run test:e2e -- --puppeteer-interactive

you can also run a given test file separately

npm run test:e2e tests/e2e/specs/hello.test.js

Writing e2e tests

The e2e tests live in the tests/e2e/specs folder and should be follow the following naming format my-file.test.js.

The e2e tests use Jest as a testing/asserting framework, and rely on Puppeteer to communicate with the browser.

A typical e2e test looks like that:

// Load utilities from the e2e-test-utils package.
import { visitAdminPage } from '@wordpress/e2e-test-utils';

// Name of the test suite.
describe( 'Hello World', () => {

	// Flow being tested.
	// Ideally each flow is independent and can be run separately.
	it( 'Should load properly', async () => {
		// Navigate the admin and performs tasks
		// Use Puppeteer APIs to interacte with mouse, keyboard...
		await visitAdminPage( '/' );

		// Assertions
		const nodes = await page.$x(
			'//h2[contains(text(), "Welcome to WordPress!")]'
		expect( nodes.length ).not.toEqual( 0 );
	} );
} );

e2e test utilities

When writing e2e test, you’ll notice that some actions are repeated across tests. Things like:

  • Login into the dashboard
  • Go to a page
  • Activate/Deactivate a plugin
  • Create a new post
  • Create a dummy page

A number of these utilities is already available in the @wordpress/e2e-test-utils package, in the Gutenberg repository. You’re encouraged to use and share reusable utilities across tests.

In addition to these utilities, you can checkout the Puppeteer API Docs to manipulate the browser.

We need you

Please give it a try, the more we add tests, the more stable our releases will be. If you need support, ask in the #core-js Slack channel.

#core-editor, #core-js, #testing

JavaScript Chat Summary, June 11, 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.

Component Props Documentation

Slack Conversation

Question: How can we eliminate human error from components documentation?

Context: @dsifford‘s recent pull requests can sort of speak for themselves so far as demonstrating the current inaccuracies in components documentation. He’s discovered them while working on type definitions added to DefinitelyTyped for @wordpress/* packages and he’s tracking progress on Trello board. If anyone is interested in helping the effort let us know.

Options discussed:

  • Improve current JSDoc documentation.
  • Add support for React.PropTypes.
  • Introduce TypeScript.

Action items:

Open Floor

Slack Conversation

Some of us are traveling to WordCamp Europe next week, so we agreed to cancel the meeting planned for next Tuesday and pick up again on June, 25th.

#core-js, #design, #javascript

JavaScript Chat Summary, June 4, 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: June 18 Meeting Planning

Slack Conversation

Neither @adamsilverstein nor @aduth will be able to host the meeting scheduled for June 18. Is there anyone willing to host that day, or should we plan to cancel the meeting for that week? This is the Tuesday before WordCamp Europe, so there may be lower-than-usual attendance.

Decision: There will be no JavaScript meeting on June 18.

Agenda: Dependabot Follow-up

Slack Conversation

Discussed in last week’s meeting, a bot has been submitting security update pull requests to the gutenberg-examples repository. It was discovered that this was a default behavior from GitHub’s acquisition and integration of Dependabot.

Proposal: If there will be a workflow which requires corresponding upstream patches for the WordPress core project, we should document it.

Since the pull requests are not being submitted to the Gutenberg repository, this workflow may not be necessary. The examples repository is standalone and is not mirrored upstream in any fashion.

Agenda: Broader Impact of Gutenberg Patterns

Slack Conversation

@nerrad raised a concern that patterns developed in Gutenberg may conflict or overlap with patterns in the broader wp-admin interface.

Example: The “Snackbar” iteration is relevant in the conversation about notifications in the administration screens.

Question: Are features which land in the plugin guaranteed to make their way to stable WordPress release? Answer: It’s not intended to be a given, iterations and feedback are to be solicited, and features can be guarded behind feature flags or dropped altogether. But ultimately, the current release workflow does result in most of these being put on a track toward a stable release.

Question: How do we avoid siloed decision-making?


  • These should be discussed beforehand in relevant teams with audiences outside Gutenberg specifically (#design was raised as having discussed this specific “Snackbar” iteration).
  • There should be some Trac conversation for the broader implications of the specific feature, and if/when this exists, regular updates should be provided to share iterations and solicit feedback.

Next Steps: Discuss the question of process for how decisions made in Gutenberg are handled in making their way to WordPress core. What are the problems, and who makes the decisions? Consider as a discussion point for a future devchat.

Open Floor

Slack Conversation

@nerrad shared that the useDispatch React hook is now available for use in Gutenberg master (pull request, documentation). This complements the useSelect React hook which had been merged last week (pull request, documentation).

@nerrad plans to publish a post about these new hooks on his own personal blog, and may cross-post or adapt the content into a post for Make/Core (this blog).

@gziolo shared that he has been making progress on improvements to the @wordpress/scripts package tools, including default paths for linting scripts, ensuring the build folder is ignored from validation (pull request), and supporting multiple entry points for build (pull request).

#core-js, #javascript

JavaScript chat summary, May 28th, 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: dependabot

@netweb started the topic by referring that dependabot was enabled in Gutenberg-examples and helphub repositories and the bot is currently creating PRs to update the package-lock.json dependencies.

A discussion about specificities about how npm versions work, what type of PR’s dependabot is creating, and why dependabot is enabled went on.

Agenda: Add type module commonjs to the corresponding packages

@gziolo referred that we have several packages which use CommonJS and questioned why not to mark them according to the new spec.

@gziolo shared the PR that applies the change referred above

@aduth asked if “type”: “commonjs” was not the default given that to be backward compatible having that default would probably be a need. @aduth added that he is looking forward to having consistent module import semantics across our packages.

@gziolo said he would do additional.

After meeting @gziolo commented on the referenced PR that he was able to confirm that commonjs is the default type, and proposed an alternative PR

Agenda: New things on the api

@nerrad referred that useSelectwas merged. And asked for thougths about useDispatch i.e useDispatch( storeName: string ): Object along with useDispatchWithMap( dispatchMap:function ): Object<function>.

@youknowriad asked:

what if it’s useStoreDispatch and useDispatch? I’m thinking that the map implementation is important for us, especially because we only want to call some selectors when the handler is called. So the question I have is about which implementation should be the default (called useDispatch)

@aduth also gave support to that approach because that way useSelect and useDispatch both accept a mapping function as an argument.

@epiqueras asked what the function gives that is not possible to do directly with the returned dispatch function?

@aduth answered that he thinks that the one thing is direct access to the registry, which is used in some places to help performance (only call a selector when the action is actually dispatched).

The alternative of useDispatch just returning dispatch right was suggested.

@nerrad referred:

I think with the move to hooks I actually prefer useDispatch to either return dispatch or actions for a specific store because typically useDispatch will be used in concert with useSelect in a component.
That provides flexibility for the component to take care of memoizing (via useCallback etc) any aggregate onClick events etc using the value from the select and the dispatches.

And referenced that useDispatch in redux does not receive a map.

For context, a link from the react-redux project was shared

People in the meeting arrived at a consensus that a good solution is just expose a single `useDispatch` without a mapping function that contains an optional parameter specifying the store name, and when called without argument just returns dispatch.

Other remarks

For people interested in GitHub Actions, @aduth explored a simple one to get the ball rolling:

Package publishes were improved with regards to managing two-factor auth passcodes:

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

JavaScript chat summary, May 21st, 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.

Maintaining Changelog

  • Updates to docs on maintaining packages change log.
  • Developers should not choose the version number for changes to packages, instead, add the changes to relevant subsection under “Master” heading.

Unstable APIs

  • Some discussion around listing and auditing various unstable APIs in use.
  • @nosolosw suggested automating the listing using JSDoc and was agreed upon.
  • These unsable API’s will be reviewed and removed on case by case basis.

Release Automation Tool

  • Current release process required manual intervention which was time consuming and prone to errors.
  • @youknowriad worked on the initial tool which helps in automating the process more details in PR

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

#core-js, #javascript

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: May 7th, 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: React Hooks offering for wordpress/data

Context | Slack

There’s a bit of discussion surrounding implementing React Hooks in the WordPress use of javascript. Here’s some take-ways/actions from the discussion:

  • Experiment with a useSelect limited example to port an existing component (initial experiments owned by @nerrad)
  • Consider the broader context of higher-order components, and the impact of hooks:
    • Which existing higher-order components can be ported? All of them?
    • Do the interfaces change in porting to hooks?
    • Would we ever find reason to create new higher-order components?

Please assist in working through this discussion. You can contribute thoughts in the related github issue.

#core-js, #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:

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