JavaScript Chat Summary: Aug. 20th, 2019

Below is a of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Thanks to @c4rl0sbr4v0 for taking these notes.

Our agenda was empty this week so all discussion arose from the open floor.

Introducing a new icon package

@nadir says that they will clean the PR of files auto-generated files and also that they were looking at a way to treeshake without the need to import individual icons manually.

There has been a discussion about including all icons in a wp.icons variable

  • Advantages:
    • Plugin developers that don’t use any build system have the ability to access our icons in their code.
  • Disadvantages:
    • We can’t load +1000 icon in a single script.

Possible solutions:

  • Select, download and manually include your icons in a web/cli tool like lodash or Material design.

This is a tough issue exploring the requirement for devs to include or not a build system and if this is overkill just to include a few icons.


Keep the discussion going in the ticket and hopefully we can arrive at a way forward.

Source maps in firefox

@pierlo asks for help with this issue:

Unable to load source maps from webpack in Firefox

@swissspidy asked if this is also a Gutenberg issue, referring a solution here


No actions debated in Slack channel.

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

Editor chat summary: 14 August 2019

This post summarizes for the weekly editor chat meeting on Wednesday, August 14, 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Gutenberg 6.3 

  • @riad noted that this release is a very important release in terms of Accessibility because it introduces the Navigation Mode

Priorities for next week

Please don’t hesitate to help there. Provide a11y and design feedback. Help with tests… Let’s move these forward.

Task Coordination

Based on the links in Task Coordination, Riad extracted a list of PRs where feedback is needed:

Open Floor

There was a discussion about new core blocks being developed. The central idea is that some ideas, while good, are low priority, for example the gists block or the multi select dropdown.

Riad explained that the ideas for the blocks themselves are good but “we added components as we needed them in Core and Core blocks. Doesn’t mean we can’t add components for third-party authors if they prove to be useful for a lot of persons but we’d need contributors to champion these”

There is also a list of new blocks that are high priority and considered “blessed tasks” and the list includes: icons, menu, social icons, divider and other Full site editing related blocks (site title, post title, post categories).

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

The agenda for the next meeting, 21 August 2019 13:00 UTC is here, please add anything you want to discuss.

#core-editor, #core-restapi, #editor, #gutenberg, #meeting-notes

Javascript Chat Summary: August 13, 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: Shared Core Dependencies


The Google Doc Agenda has much of the content of what was discussed, but as a summary:

Package/Bundle size for assets is a significant concern for frontend use as WordPress continues to expand javascript as a first class citizen in its ecosystem. Some examples where this surfaces are:

  • using wp.element on the frontend. It has a dependency on lodash which adds weight to page load.
  • implementing various components or blocks on the frontend (wp.components itself has significant size).

Some potential ways to resolve/improve this for not only frontend but also admin are:

Load externals via CDN.

Externals such as react, react-dom, lodash etc could still be registered but the source would be from CDN. The advantage here is with WP’s wide reach, it’s much more likely that client browsers will have cached the asset for visitors to WP sites. Currently that’s less likely because of every site hosting it’s own assets by default.

Action: @adamsilverstein is going to raise this in the hosting meeting to get feedback from there.

Size of packages.

Here, the focus is on how big are we willing to allow various bundles to get? For instance wp.components is 553kB minified.

  • should we start thinking about setting some comfortable limits on how big we allow bundles to get? (tools like bundlesize could help with that)
  • what ways can bundles be further reduced in size (example of @wordpress/server-side-render being extracted into it’s own package) – audit packages and see what other extractions/groupings can be done?
  • WP core supports script-aliases (enqueuing wp-components could actually enqueue X different files behind the scenes, all populating the wp global).
  • Reduce external dependencies: Example is lodash dependency removal from @wordpress/element. Much of the functionality of lodash can be implemented via native js.


  • It’d be good if those interested in javascript in WordPress start thinking through some of what’s been discussed in this item and contribute some proposals on how to improve things.
  • On the last item, removing lodash dependency from WordPress packages has been proposed. It’d be nice to get a decision on moving forward there. Please contribute your thoughts to the issue!

Agenda: Lazy Loading of Images and Frames

Slack | Trac | lazysizes library | Native lazy-loading for the web article

The discussion here centered around whether lazy loading of images is something that should be implemented in WordPress core and some initial ideas on what would be involved in doing that. Some highlights of the discussion (though no concrete decision was made):

  • opt-in for now
  • possibly implemented via add-theme-support
  • include for wp-admin as well (eg. Media Library)


  • continue to contribute to the trac ticket. Possibly explore landing something for wp-admin first.

Open Floor

  • @joyously asked about the status/possibility of updating jQuery (see trac ticket (slack convo). Nothing concrete from the discussion. Current blockers are the difficulty in resolving issues with the update and conflicts/failures with the customizer and media. Also reluctance exists to invest effort in something that may become obsolete due to changes in framework used (moving to more react heavy admin). Joy did note that the biggest problem existing right now are the flags raised by security scanners detecting the version number (author note: vulnerabilities in jQuery bundled with core are patched, but security scanners still detect it as a vulnerable version).

#javascript, #meeting-notes

Editor chat summary: 7 August 2019

This post summarizes for the weekly editor chat meeting on Wednesday, August 7, 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Task Coordination

Open Floor

@karmatosed and @chrisvanpatten brought up the need for leadership in user focused documentation for Gutenberg.

Graphics requested for Gutenberg documentation can be found on the Design team’s board.

@paaljoachim offered to reach out to the docs team for assistance in moving forward. If you’re interested in helping with user-focused docs for Gutenberg, please reach out in the comments here or in the #core-editor channel!

@kadamwhite mentioned that the REST API team is working on catching up with requests for feedback on tickets and invited folks to the the #core-restapi channel to connect.

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

The agenda for the next meeting, 14 August 2019 13:00 UTC is here, please add anything you want to discuss.

#editor, #gutenberg, #meeting-notes

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

Editor chat summary: 26 June 2019

This post summarizes the weekly editor chat meeting on Wednesday, 26th June 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Gutenberg 6.0

Gutenberg 6.0 was released and includes various fixes and improvements including a way to pick a pre-defined layout in Columns block.

WordCamp Europe


Folks discussed the difficulty in attribution of work in props due to a manual process being used to collect it. This has caused some contributors be missed in the last few releases.

@youknowriad requested help from someone to research GitHub/ username matching.

Folks seemed to agree that the most immediate step would be to list props in the merge commit, which would be similar to the way Core handles them.

There was also discussion about what constitutes a contribution, with discussion leaning towards the core description.

Many favor automating the process as much as possible, with some concerned that this would include folks that commented in unhelpful ways.

@desrosj agreed to create a post on the subject, summarizing and listing actionable items and proposals. He also requested feedback from those not aware of the topic of conversation or who were not able to attend WCEU.

Themes, Content Areas, and Editing more than post_content.

There was discussion on how themes could best register content areas, and how the editor should best expand to edit content outside of post_content.

@youknowriad created three issues to hold the discussion, with more likely to come:


@matias recommended a focused chat with the themes group, and many folks agreed.

Task Coordination

Open Floor

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!

The next meeting is scheduled for July 3, 2019 at 13:00 UTC. The agenda is here; please add anything you’d like to discuss!

#core-editor, #editor, #gutenberg, #meeting-notes

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

Editor chat summary: May 8

This post summarizes the weekly Editor meeting on Wednesday, 8th May 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Volunteers for Note-Taking Requested

As there are not very many folks who are taking notes for the chat at the moment, volunteers were requested. @nosolosw, @andraganescu, and @jorgefilipecosta offered to help out.

WordPress 5.2

WordPress 5.2 was released! Thanks to everyone who helped!

@youknowriad noted that he wasn’t sure why all of these things weren’t highlighted in the release post, but updates include:

  • No more TinyMCE in blocks
  • Block Management UI
  • Performance more than doubled in async mode
  • All widgets ported to blocks
  • A lot of improvements to existing blocks (cover block with inner blocks, focal point picker,…)
  • Stability improvements
  • Zero-config scripts to help authors create blocks

Accessibility Audit

The accessibility audit has been published. This is a great resource to improve the accessibility of the editor. Thank you to everyone that worked on it!

@andraganescu, @karmatosed, and @mapk attended the Accessibility chat to collaborate (recap was posted on the agenda post).

Design has done two triage sessions focused on the report (the next is on Friday, May 10, 2019 at 14:00 UTC), and development has already started in fixing some of the issues found.

The project board can be found here, and issues are also being grouped into labels (like [a11y] Keyboard & Focus). There’s interest in solving all validated issues that were found.

Several folks expressed interest in an a11y focused WordPress release, with the note that it would need to be a broader conversation with core + leadership.

@bemdesign mentioned, and others agreed, that while automation can help, a11y should ultimately be built into the process. Tenon, the company that ran the audit, provided documentation on how they tested.

Some recommended next steps included:

  • Aim for closing the project board by the end of May
  • Focus all triages until that can happen
  • Consider adding a column for deeper conversations / focuses and make issues for those
  • Dev-triage session focused on the board next week (Monday)
  • If you’re looking for an issue to tackle, take a look at this board first 🙂

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

Open Floor

@karmatosed asked if anyone would be interested in working with them on more detailed RC notes to be included in calls for testing.

@aduth raised a question about merge permissions.
“Is there a good sense of criteria for this to be granted? Or similar to core committer status, at discretion of leadership?”

Folks present seemed to be in consensus that this should be clarified, even if it’s only in terms of documenting general expectations.

Recommendations on criteria often included a number of contributions (committed PRs or other activities), ranging from 3-10 — with a note from @gziolo that Gatsby automatically adds access after one.

In closing, a quote from @andraganescu, “The thing with merge access is that as long as we have the triage/review/automated testing process the only thing you need is to prove some kind of good faith I guess”

Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on 15 May 2019 at 13:00 UTC, is here; please add anything that you want to discuss.

#accessibility, #core-editor, #editor, #gutenberg, #meeting-notes

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, 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

@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

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

@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

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

@nosolosw announced that in the past days the first auto-generated API documentation was merged to the Gutenberg repository:
The tool that autogenerated the documentation is proposed in
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