JavaScript chat Summary – August 21

Below is a summary of the discussion from this week’s JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. 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

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party 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.