Javascript Chat Summary – September 11th

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.


  • WordPress packages are using Babel7 and the @wordpress/babel-preset-default has been updated to support it.
  • The packages do not include the polyfills by default anymore. It’s the responsibility of the consumer to add the required polyfills to their applications or bundles. The context for this change can be found on this issue.
  • WordPress (via Gutenberg) exposes a new script wp-polyfill-ecmascript (and will be simplified soon as just wp-polyfill) that you can add as a dependency to your script to ensure the polyfills are loaded.


  • Having a separate polyfill script even without conditional polyfill loading is still a decrease in bundle size (Gutenberg is 118.64kb smaller).
  • We also discussed whether to include “web” polyfills in the wp-polyfill-ecmascript instead of including them per dependency. A decision was made to have a unique wp-polyfill script you can depend on and use all the polyfills made available by WordPress. This script would include both ECMAScript polyfills and also different Web Standards that require polyfills such as window.fetchor element.closest. This results in a better developer experience as it’s not always easy to know what polyfill is needed for per script.

Action items

#core-js, #javascript, #summary

Javascript Chat Summary – September 4th

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: Deprecation policy

Slack Conversation

Gutenberg has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin developers to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.

It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:

  • Packages follow semver, so something could be removed in a major version, ie. 3.0
  • Then the package adds a deprecation warning in a minor version before that, ie. 2.x
  • The deprecated call as used by packages wouldn’t include anything specific about Gutenberg, but somehow Gutenberg extends the message it logs (by filter), analyzes the generic deprecation version (the npm SemVer) and maps it back to an equivalent Gutenberg / WordPress release.


  • Explore extensibility of deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)
  • (Re-)consider how and where to define boundaries between packages and core-specific JavaScript (proposal by @atimmer, @omarreiss)

Open floor: Also allow building in src

Slack Conversation

The build step that was introduced in #43055 seems to cause quite some friction for PHP development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.

It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.


@omarreiss will work on a patch.

Open floor: Guidelines for including WP packages

Slack Conversation

Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:

  • if the plugin author needs to backport these API’s or not in order to support classic editor.
  • If the plugin author uses ES2015 or older versions of JS.
  • If the plugin author uses a build proces.


@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.

Javascript Chat Summary – August 28th

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.

Agenda: Preparing for Gutenberg Merge

Slack Conversation

What tasks do we need to complete on the core side to be ready for Gutenberg Merge?

Prior Work

Remaining Tickets


What? Who?
Experiment with the following steps to see how this works:

WordPress side:

– Gutenberg packages stay where they are
– Gutenberg’s PHP (script registration and bootstrapping) move to core.
– Webpack config to alias wp.* to npm dependencies moves to Core’s webpack config.

Gutenberg side:

– Kept as plugin for ease of maintenance, updates.
– Plugin re-register’s the scripts (overriding wp’s registrations)
– No more php bootstrapping in the Gutenberg repository.

Some experimentation could involve consuming packages in WordPress core.

Example: Usage of shortcodes.js could be replaced with @wordpress/shortcodes

edit-post needs to be moved to a package.
Resolve componentsand block-library which have some code that lives outside packages.

Agenda: Hooks

Slack Conversation | Context

The following things were discussed:

  • Standards for naming/namespacing hooks
  • Criteria for adding/accepting a new hook
  • Expanding documentation for available hooks (including inline documentation)
  • “All” hooks.

No clear resolution to the above points was made in the meeting.

Agenda: Babel 7 & Polyfills

Slack Conversation | Context


What? Who?
Decision: Ship packages without any polyfills, then bundle all polyfills in WordPress core.  Documentation will include something like this:

This package assumes that your code will run in an ES2015+ environment. If you’re using an environment that has limited or no support for ES2015+ such as lower versions of IE then using core-js or @babel/polyfill will add support for these methods. Learn more about it in Babel docs.

Agenda: Converting from lodash to lodash-es for distributed packages

Slack Conversation | Context


What? Who?
Continue discussion on the related issue.  

Dev Chat Summary: August 22, 2018 (4.9.9 weeks 1 & 2)

This post summarizes the weekly dev chat meetings held Wednesday, August 15 and 22, 2018 (August 15 agenda | August 22 agendaAugust 15 “tidechat” Slack archive |August 22 Slack archive).

It’s a two-for-one chat notes bonus! Lucky you, Internet.

4.9.8 Feedback

Most importantly, we are grateful that we’re receiving so much feedback, and genuinely empathize with the inevitable frustration that accompanies developing and using new features.

Unfortunately, we have to address some of the unproductive communication contained in some feedback submissions, even going as far as to personally attack Gutenberg contributors. It’s easy to submit negative feedback when you don’t have to look someone in the eye, but there are IRL humans with IRL feelings who receive and address those tasks. 

If you are providing feedback please follow the WordPress Etiquette and Support Forum Guidelines. Utilizing respectful, productive phrasing is also a fantastic way to ensure your submissions are taken seriously and acted on swiftly.

4.9.9 Planning & Lead Nominations

  • We don’t have a hard timeline yet for 5.0, so once we select leads for 4.9.9 it’s looking like a regular 6-8 week maintenance cycle.
  • This is likely the last week for 4.9.9 lead nominations. Non-engineers can be leads, too! Nominate your pals or nominate yourself – by leaving a comment here or DMing @jeffpaul

Focus Lead & Component Maintainer Updates


So many enhancements and Guten-bug* fixes over the last few weeks:

Also, pay special attention to this issue overview on introducing and/or extending PHP APIs.

*You’re welcome.


  • The REST API team met earlier this month to discuss 5.0 planning, meta handling and authentication. 
  • If you’re interested and available, the REST API team is looking for a lead contribution for the authentication plugins. Hit up @kadamwhite directly or mosey on over to the #core-restapi channel.


More chats!

  • August 14, 2018Highlights: Optimizing WordPress package distribution using NPM
  • August 21, 2018 | Highlights: Use of globals, lodash import, polyfills for built-ins, a proposal for managing packages, and including vendor scripts in plugins.



Tide 1.0.0-beta has come ashore!* What is Tide? 

Tide is a series of automated tests run against every plugin and theme in the directory and then displays PHP compatibility and test errors/warnings in the directory.

– I copied/pasted this from here

The Tide team can be found at #tide in Slack, and welcomes input for release candidate inclusions for an eventual 1.0.0 release. 

*I’m sorry.

General Announcements

It’s been awhile since we evaluated the weekly <dev chat> schedule, so here we are. Some options discussed included:

  • Alternating time zones every other week
  • Having two chats in one day at different times
  • Moving everyone to NYC and @joemcgill will pay all expenses

This is a call for a lovely person or two to help us coordinate a second/alternate <dev chat> time. 

Comment on this post or message @jeffpaul and/or me in Slack.

The next <dev chat> will take place on Wednesday, August 29, 2018 20:00 UTC in the #core Slack channel. Please drop in with any updates or questions. If you have items to discuss, drop a comment on next week’s agenda post, so we can take them into account. 


JavaScript chat Summary – August 21

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.

Use of globals

Gutenberg is eliminating the implicit use of globals. They encountered an issue where the WordPress JS coding standards still allow the wp global. This makes it harder to check where Gutenberg is using it. 

@atimmer mentioned that that code standards should be global agnostic as the globals that a project uses is specific to the project.

Action item: Remove the global definition and move the ESLint configuration into a@wordpress scoped package.


A new package has been merged (not yet published to npm), @wordpress/token-list:

This is intended to provide the same usability offered by Element#classList, without requiring a DOM node to work with.

Probably not much to discuss on this one, consider it more an announcement of availability :slightly_smiling_face:


Lodash import

In the development of token-list @aduth tried using lodash-es as the Lodash dependency instead of lodash. In the eventual implementation he reverted this, but he asked input on whether people thought this was a good idea. In general people agreed that this would be the way forward.

Action item: Convert lodash imports in @wordpress/packagesto lodash-es imports.

Polyfills for built-ins

@gziolo has created a PR to improve how built-ins are polyfilled. The PR has a good description of the changes, a small summary is:

  • We no longer use corejs: 2 flag when building distribution version for packages.
  • We no longer use builtIns: "usage" in the same process.
  • We use them when Webpack does its magic to produce WP specific bundles.

The biggest change is that every time someone uses npm package, they need to apply polyfills themselves. The reason for this is because the polyfills were causing bloat while not everyone might need them.

One of the remaining questions was if the module build should still include transpilation down to ES5 compatible code, or if it should use features that all browsers support that support <script type="module">. Another question is which polyfills should be included in that build.

The rollup wiki has a good page describing what should be in a module build, but makes no mention of polyfills. @gziolo will research this issue a bit more and come back with his conclusions in a later chat.

Proposal for managing packages

The proposal for managing packages has had some updates since last week. This specifically includes some additions to move the burden of version assignment to the developer proposing the changes.

There was a remaining question about how granular the changelog should be kept. @aduth came up with a simple guideline: “If you struggle to classify a change as Breaking, New Feature, or Bug Fix, then it’s not necessary to include.”

Including vendor scripts in plugins

A question came up in #core-editor about how a plugin might want to consider including Lodash right now. A solution was shared that would register lodash if it wasn’t currently registered. This also goes for other vendor scripts. The chat then discussed how we could deal with updating libraries in WordPress and plugins registering their own versions. We didn’t get to a resolution.

REST API chat summary: August 9

This post summarizes the REST API component team chat from August 9 (agenda, Slack archive).

5.0 Priorities

The REST API team’s primary goal for the next major release is to support the Gutenberg team. There are still a number of REST API-related issues open in the Gutenberg merge proposal milestone; we always welcome assistance in getting these taken care of.

Issues that were raised as needing eyes and opinions:

  • #44758 (handling user’s locale in REST API responses)
  • #39953 (handling dates on draft posts)
  • gutenberg#8683 and gutenberg#2457 (supporting Gutenberg use with custom controllers and REST routes outside of the wp/v2 namespace)

Outside of Gutenberg, the two major areas of development we aim to tackle are

  • further improvements to the API’s support for meta,
  • and authentication.

Meta Handling

Following the register_meta improvements in 4.9.8, we wish to continue improving the state of meta handling and registration within the REST API.

  • @flixos90 will be re-opening the discussion around how to register complex meta values (e.g. permitting associative arrays instead of just integers, strings and the like). See #43392.
  • #43941 (support default values for registered meta) has clear potential benefits to users and will also be prioritized.
  • @spacedmonkey and others are driving additional tickets which could benefit meta handling, including #44387 & #44238.


We aim to release a tested version of the OAuth 2.0 plugin to the plugin repository by the end of the year. This will greatly assist application developers who wish to integrate their WordPress site with external applications. We are also interested in pursuing a basic auth solution within core (see discussion in #42790).

As @rmccue is currently unavailable to lead development in this area, we are opening a call for a lead contributor to the REST API authentication plugins. We need somebody to own the vision for how external applications should authenticate with WordPress.

Agenda for today’s meeting

The REST API team will be meeting shortly (now, in fact…) in #core-restapi for our regular weekly meeting at 2018-08-16T17:00 UTC. As always, if you have a REST API related ticket you would like to bring to the component team’s attention, please join us or leave a note in the #core-restapi channel. Hope to see you all later today!

Javascript Chat Summary – August 14

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.

This week we discussed WordPress packages and how to optimize their distribution using npm. As of today, Gutenberg is built of 41 packages where each of them can be used independently by every plugin and theme developer in their projects.

Duplication concerns over independent versioning

Slack Conversation

Problem: An issue was raised about our independent versioning of packages, and how this can lead to duplication which, for packages like data which behave as a singleton, can result in some pretty undesirable outcomes. Related comments on GitHub:


  • This is not specific to @wordpress/data, and could affect anything which behaves in a global / singleton fashion: @wordpress/hooks@wordpress/filters@wordpress/blocks.
  • The issue is mitigated but not eliminated by moving away from Lerna independent versioning (toward fixed versioning) because the chance for differing versions still exists.
  • This shouldn’t be an issue in WordPress context at all. This seems to be an issue for external apps which consume WordPress packages directly from npm.

Decision: Avoid “globals” behavior, where a consumer must define and operate with its own registry (specific to @wordpress/data).

Action items:

How required built-ins should be polyfilled

Slack Conversation

Problem: The current npm packages that being built for Gutenberg polyfill usage of some browser features that are not available on older browsers. This polyfill is global and affects any client who uses WordPress npm packages. This is unexpected and can alter the runtime environment in surprising ways. More details in the related issue.

Decision: corejs flag should be set to false when generating distribution version for packages and set to 2 when bundling with Webpack. In addition, we should inform developers consuming WordPress packages to install proper polyfills on their own.

Guidelines for releases

Slack Conversation

Proposal: We have a documentation proposal to improve guidelines for creating, managing and publishing packages.

Observations: The versioning recommendations are very oriented toward deprecations which seems to be the right approach.

Action item: Add section about managing changelogs based on the discussion from last week.

Dev Chat Summary: August 08, 2018 (4.9.9 Week 1)

This post summarizes the weekly dev chat meeting held Wednesday, August 08, 2018 (agenda | Slack archive).

👉🏼💥 Release Lead Nominations 💥👈🏼

It’s time to select release leads for our 4.9.9 maintenance release. Hooray! If you’d like to nominate someone, or yourself, add a comment to this post. Don’t be shy, y’all.

What does a release lead do? Here are some good resources: 

🔥 Hot Tip 🔥 You don’t have to be an engineer to be a release lead.

4.9.8 Release Feedback

  • Check the goodies in the maintenance release post, if you haven’t.
  • Big thanks to @pbiron, @joshuawold, @sergeybiryukov, @psykro and Mission Control. 🙌🏼
  • @pbiron plans to post a retrospective similar to this in the next week or two.
  • Overall, the Try Gutenberg callout has been effective in getting people to use Gutenberg and find bugs. Active users jumped from 20k to 100k in just a few days. 
  • The support team reports via @clorith things have been pretty quiet since the release. More info inbound on wider areas of focus for support, so stay tuned.
  • There are some reported issues to jump on:

4.9.9 Planning

  • We’re all going proceed as if we’re doing a 4.9.9 maintenance release, so keep working on the growing list of tickets here.
  • However, as of today, we aren’t committed to a 4.9.9 maintenance release. Why?
    • There is not a rush to get a maintenance release the door
    • We don’t have committed leads yet (see above)
    • So far, we don’t have any significant issues from 4.9.8 that require attention

Focus Lead and Component Maintainer Updates


  • The REST API meeting is today – August 9, 2018 – at  17:00 UTC. Welp, this already happened.
  • The key agenda items are: 
    • Prioritize register_meta improvements for 5.0
    • Review API-related Gutenberg tickets
    • Selecting and prioritizing additonal backlog tickets for 5.0



Thank you to all who gave us feedback so far! The feedback is being processed and iterations are underway. 

Open Floor

Post counts on on shared taxonomy terms 

Via @davecpage. There are multiple tickets open related to this:

These are all related to the taxonomy component, and we’ll currently slate them for release in 4.9.9.

General Announcements

Dev Chat Coordination: The Sequel

@jeffpaul is ill and will hopefully return next week. Until he’s at full strength, @joemcgill@audrasjb@antpb and I will continue to run dev chat.

Next Meeting

The next meeting will take place on Wednesday, August 15, at 20:00 UTC in the #core Slack channel. Please drop in with any updates or questions. If you have items to discuss, drop a comment on next week’s agenda post, so we can take them into account.

Javascript Chat Summary – August 7

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.

Automating Publishing to npm

Slack Conversation

Problem: Publishing modules to npm can be difficult because it is not always clear at the time of publishing to what version the package should be updated. The individual performing the publish is not always the same as the contributors who had proposed changes to the package.


  • Adopt conventional commits to enable automatic versioning (pull request)
    • Issue: This is hard to enforce
  • Encourage developers to introduce relevant changelog entries as part of proposed changes. The type of change should indicate versioning requirements.
    • Issue: Not every version bump is caused by directly by new changes, sometimes indirectly by updated dependencies.
    • Issue: Prone to frequent merge conflicts with many developers adding entries to the same text file.

Decision: Encourage developers to introduce changelog entries and evaluate success in a future meeting.

Package Deprecations Versioning

Slack Conversation

Problem: When deprecating a feature in Gutenberg, we add logging to highlight the deprecation, and allow for two minor releases of the plugin before removing the functionality. With this in mind, how do we handle versioning of modules? Following SemVer, the major version should be bumped on backwards-incompatible changes. If the deprecation is not entirely faithful and therefore introduces a breaking change, it results in the need for two separate major version bumps by the removal of a single feature.

Discussion points:

  • Is this really a common use case?
  • Could it be considered a good thing to promote the idea that deprecation “shims” should be fully compatible?
  • How does SemVer consider deprecations?
    • Very specifically: “Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.”

Decision: The major version should be bumped on any backwards-incompatible change. This will usually occur at the final removal of the feature. The deprecation should be fully backwards-compatible and, if it is not, it should warrant a separate major version bump.



Slack Conversation

Problem: There are several inconsistencies between the WordPress PHP implementation of add_query_arg and the parallel addQueryArgs from the @wordpress/url package:

Name pluralization: addQueryArgs (JS) vs. add_query_arg (PHP)
Arguments: url, param (JS) vs. param, url (PHP)
Usage: Object only (JS) vs. object or key+value pair (PHP)

Discussion points:

  • Consistency vs. improvements
  • Real-world workflows where developers will expect JavaScript reimplementations to behave the same as their PHP counterpart.
  • In general, we should seek to avoid confusion in appearing similar if in-fact the behaviors are not the same.

Decision: There will be no changes to the name or argument order of the addQueryArgs function. Supporting key and value arguments may be a separate enhancement to consider.

Data Plugins API

Slack Conversation

Announcement: The @wordpress/data module now supports a plugin API. Persistence behaviors, which were previously baked in, are now extracted out to an opt-in plugin. This should help improve isolation of specific behaviors, and allow external consumers to use only specific features relevant for their products.

A new pattern for asynchronous state behaviors has been implemented, distributed as the @wordpress/redux-routine package and integrated with the @wordpress/data module via a new controls plugin.

DOM Ready

Slack Conversation

Announcement: A fix has been backported from the Meta team into the @wordpress/dom-ready package, addressing an issue where callbacks may not be called reliably if the document was in specific states. This was the cause of intermittent white-screen issues on the Gutenberg marketing page.

Open Floor

Usage of wp.api

Slack Conversation

Question: Do we still use wp.api ?

Answer: Only in the (now-deprecated) withAPIData higher-order component. Once this deprecation is complete, there will be no more usage of wp.api and it can be safely removed.

Dev Chat Summary & Call for Release Lead Nominations: August 01, 2018 (4.9.8 week 5)

This post summarizes the weekly dev chat meeting held Wednesday, July 18, 2018 (agenda | Slack archive).

4.9.8 Release

4.9.9 Road Map

  • Rumors of a v. quick release (like next week) for 4.9.9 were squashed. 
  • There are currently 46 tickets assigned to this milestone.
  • See the “Call for Release Leads” section below.

Focus Lead and Component Maintainer Updates

Recap posts within a recap post. Woah.

General Announcements

Devchat Coordination Reminder

@jeffpaul returns next week, thus ending the mighty reign of temporary dev chat leads @joemcgill, @audrasjb, @antpb et moi. Please tell him how truly fantastic we were in his absence.

Next Meeting

The next meeting will take place on Wednesday, August 08, at 20:00 UTC in the #core Slack channel. Please drop in with any updates or questions. If you have items to discuss, drop a comment on next week’s agenda post, so we can take them into account. 

(You can add them as a comment here, too, but they might get lost in the flurry of release lead noms.)

Call for Release Lead Nominations

Here we go. It’s time to nominate leads for 4.9.9.

  • Post a comment on this recap to be considered. 
  • You do not have to be an engineer to be nominated.
  • Self-nominations are welcome.
  • Ready? GO!