JavaScript chat summary, February 5th, 2019

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

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

Agenda: Changelogs

Slack Conversation

In a previous discussion a need surfaced to improve Semver for JS packages and better understand the changes we are syncing into WordPress core when we update the JS packages. For this, better changelogs are needed. @aduth has been working on a PR to enforce better changelog management. It explores adding a pre-commit githook which verifies that the contents of the pending commit include a CHANGELOG.md revision if applicable.

Some concerns were raised about the potential unwanted friction a githook could give and false positives that could occur when ie. committing typo fixes. A possible alternative is to make the check part of the Travis build for PR’s. On the other hand, the direct feedback gotten through the githook contains higher educational value and minimizes loss of context.

We agreed the current githook proposal was worth exploring further in order to see if false positives can be prevented.

Agenda: Code owners

Slack Conversation

A pull request which adds an initial implementation of a CODEOWNERS file in Gutenberg was merged.

You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

Github Help

Contributors are invited to PR the file if they feel they would like to be added as a code owner for specific paths in the Gutenberg repository. When accepted, they will receive pull request notifications and review requests for these parts of the codebase.

The main goal is to alleviate some review pressure for the Gutenberg team and help distribute notifications and help requests better over more contributors. It was argued it could be good to have some guidelines for approving / merging PRs in order to allow new contributors and code owners to review with more confidence. The use is expected to further evolve and be evaluated in the coming weeks.

Agenda: Registry selectors

Slack Conversation

For a while now we’ve had the option to register multiple stores across multiple registries using the core/data package. But how can we create selectors which derive data across multiple stores / registries? A PR to tackle selecting data over multiple stores has been created by @youknowriad. Input and feedback is requested.

An effort that depends on this is a PR which tries to make the editor module more generic so it can be reused outside of WordPress. We need to be able to respect backwards-compatibility while moving selectors and action dispatchers from one module to another. See also: https://github.com/WordPress/gutenberg/pull/13088

Open floor: React hooks

Slack Conversation

React hooks has been included in the latest release of React. There is a PR on Gutenberg which explores the possible advantages of this new API: https://github.com/WordPress/gutenberg/pull/11161. Since Gutenberg relies heavily on React, it could be worthwile checking out the API and the ways it could be leveraged in Gutenberg.

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

Javascript Chat Summary – January 29, 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: Unstable APIs

Slack Conversation

There was a conversation recently on Github where it became evident that marking an API as unstable is not sufficient enough in its own right to scare people away from using them (and subsequently being frustrated that they’re not documented).

This was a lively discussion around whether there are programmatic ways to make it harder for people to use things marked __unstable .

Due to the fact there aren’t a lot of occurrences of __unstable in the code currently, the general consensus seems to be that if people are using __unstable that is a risk they are taking and there shouldn’t be worry about removing it because it’s purpose is clear.

However, this could be revisited in the future if we see usage pick up and ideas mentioned in the meeting may be explored further then.

So readers, TAKE NOTE – use anything prefixed with __unstable at your own risk. Expect your code to break in the future if you are implementing it!

Agenda: New ESLint Rule

Slack Conversation|Related Github Issue

A new rule was introduced, no-unused-vars-before-return

Agenda: Yarn future (fyi)

Slack Conversation | Related Yarn Github Issue | Related Earlier Slack Discussion

Some discussion around some potential benefits this roadmap could have should yarn be adopted for WordPress builds in the future:

  • Yarn as an API (which could open the door to controlling some things from a GUI). This could allow for building easier developer tools.
  • Yarn as a package manager platform – which means there could potentially be one package manager for both npm and packagist.
  • Improvements to mono-repo management (in terms of managing both js and php packages)

This was mostly presented just to get on everyone’s radar. There’s nothing actionable at the moment.

As an aside: if you become aware of interesting developments in the javascript world, please do include them as fyi’s in #core-js meeting agendas!

Agenda: Package alignment with core

Slack Conversation | Related Make Post

@desrosj presented how looking at this trac ticket got him thinking about how we can better align package versions with Core to prevent issues like what popped up there.

Summary of what could become a proposal:

  • In simplest form, change version constraints in the package.json
  • When a major WordPress version is released (say 5.1), the versions of each package become restricted to only minor and patch updates to @wordpress/* packages and dependencies. This allows someone to run npm update when preparing a WP minor release (5.1.1) for beta.
  • When a new major WordPress version is prepared, a new major version of the Gutenberg packages would be released (if necessary), and WP core would be updated to use that new version. This next WP version (5.2) would be locked to that next version’s patch and minor updates only.
  • From a process standpoint, this would require the Gutenberg branches to somewhat match core’s. There would need to be a 5.1 branch after that is released. Instead of cherry picking changes by using package versions, we could only back port the appropriate changes to that branch and publish the X.X or X.X.X versions of those NPM packages

The difference between what is currently being done and what is being proposed is that whenever there is a major release of WordPress, all versions of packages will be bumped with major or minor (as opposed to patch).

One reason this was brought up is concern for how security patches etc will be back-ported to earlier WordPress versions in the future

Next Steps

  • Tighten up semver in @wordpress/* packages which means enforcing proper usage of CHANGELOG.md and properly differentiating between minors and patches. (No owner currently)
  • Explore more automation of the package management/updates in WordPress core (No owner currently)
  • This does need revisited in future meetings. Work should be done on identifying clearly the problems needing solved.

#javascript

JavaScript chat summary, January 22nd, 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: NPM Scripts

Slack Conversation

A few new commands have been proposed for addition to the @wordpress/scripts module:

  • build and start: https://github.com/WordPress/gutenberg/pull/12837
  • format: https://github.com/WordPress/gutenberg/pull/13394

The discussion around build and start focused mostly on the question how to approach default configuration for plugins and themes. We’re considering to extract parts of the Webpack config as npm package to simplify setup for plugin developers. This would also allow to provide a default config for @wordpress/scripts and proposed scripts. To provide flexibility, it was raised that an eventual Webpack config package could have 3 types of exports:

  • A full webpack config with a simple preset entries map for simple starter plugins ( front.js, admin.js, blocks.js or something like that ) to provide a simple zero-config option
  • A function that takes an entries map and outputs the full webpack config with recommended values.
  • Each part of the recommended config as their own keys.

The discussion provided good input for further iteration. Next, progress was shared on the format command, which aims to provide autoformatting functionality using Prettier and Eslint autofixers. It is still in an experimental state, but would provide a powerful tool for developers to more easily adhere to coding standards.

Agenda: Linting

Slack Conversation

We discussed the lack of ES2015+ rules in the WordPress JavaScript coding standards. A pull request was proposed on Gutenberg which makes using Object shorthand notation required for Gutenberg JavaScript. We agreed this was a desirable standard to have for ES2015+ code. For now, we decided to include the rule in the Gutenberg coding guidelines until a formal proposal to include ES2015+ rules in the WordPress JavaScript coding standards is drafted.

Agenda: E2E tests in core

Slack Conversation

Progress is being made on making Gutenberg’s e2e test functionality reusable for WordPress core and beyond. @gziolo gave the following status update:

  • Added package for Axe API integration with Jest and Puppeteer: https://github.com/WordPress/gutenberg/pull/13241. This is set of tools for accessibility static analysis which we want to integrate with e2e tests to ensure that we can catch regressions early on.
  • Extracted test utils to their own @wordpress/e2e-test-utils package: https://github.com/WordPress/gutenberg/pull/13228. It will allow some code reuse for those who would like to start writing e2e tests for their WordPress sites, plugins or themes.
  • Moved tests to their own @worpress/e2e-tests package: https://github.com/WordPress/gutenberg/pull/12465. There are now located in packages/e2e-tests/specs folder.

@gziolo plans to continue working on enabling a11y support to e2e tests in Gutenberg next. In order to start reusing the e2e setup in WordPress core, quite some configuration is still needed in WordPress core. This is tracked in https://core.trac.wordpress.org/ticket/45165. @adamsilverstein agreed to explore this further.

Agenda: PropTypes and React Doc Generation

Slack Conversation

@ajitbohra proposed to add PropTypes to components in Gutenberg, in order to allow automated documentation generating and have type checking for components.

There was interest in the idea but also some concerns were raised:

  • There is some uncertainty of PropTypes’ future, considering that Facebook doesn’t use them and there exist other type systems which supersede them (Flow, TypeScript). PropTypes seems like a good solution for what we need right now, but in terms of type system, there might be better solutions available.
  • If they’re added, we need to make sure they are added as part of a proposal which also includes how they are going to be used, ie. for auto-documentation.

For now, we decided to avoid to add complexity without clearly understanding the merit. More exploration is needed on auto-documentation and the benefits of strong typing.

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

JavaScript Chat Summary – January 15th

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 the next meeting’s agenda.

Open floor

Our agenda was empty this time. This is the topics we discussed:

#javascript

JavaScript Chat Summary – January 8th

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 the next meeting’s agenda.

Revisiting Note Takers for 2019

A rotating set of volunteers are responsible for publishing these chat summaries. The topic was raised as an opportunity to make additions or removals from the rotation. Thanks to @ajitbohra and @jorgefilipecosta for adding themselves to the rotation!

In addition, there was some question to the intended format of the summaries. @nerrad has since added a new “Guidelines for Note Takers” section to the same Note Takers document.

Reviewing Documentation for Accuracy Post-5.0

It was briefly discussed in our previous meeting that it may be worth auditing older documentation to ensure that the content remains accurate, particularly with consideration of the substantial JavaScript changes and patterns which had been introduced as part of 5.0.

It was suggested to coordinate with the docs team to better understand where to start, and what documents might be relevant for auditing.

Ideas for Handling Future Deprecations

A preliminary discussion was held to surface ideas for how deprecations may be handled in the future. This has been discussed in previous meetings, and in the post Technical Organiziation Post-5.0. This discussion was more on the point of anticipating the challenge, moreso than addressing specific deprecations.

A few ideas were raised / recapped:

  • Using script versioning such that a plugin author opts in to the newest version, dropping deprecations out of the fact that they are no longer referenced by any plugin or core code.
    • There are significant technical challenges involved in this approach.
  • More communication over that which has been part of Gutenberg’s approach to deprecations.
    • More visible messaging as a “deadline” approaches (e.g. notices)
    • Integrating with upgrade process for WordPress, identifying conflicts between plugins and newer versions

Transparency was noted as critical to any process changes here, particularly in education and communication in how and when these deprecations occur.

Finalizing Standards Revisions

Revisions to the JavaScript Coding Standards has been a long-held discussion for prior meetings, culminating in a proposal published mid-December.

There was a recap of comments made to the proposal, summarized as largely favorable.

The revisions are planned to be applied to the coding standards today, after a small suggested clarification is made.

#javascript

JavaScript Chat Summary – December 18th

Below is a 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 agenda (January 8th).

Next meeting

This is the last meeting of the year. The next meeting will be held on January 8.

WordCamp US contributor day

A lot of fruitful contributions and discussions happened during the WCUS contributor day:

  • @herregroen made some progress toward improvements in how JSDoc are extracted and surfaced to developer documentation. More info in this slack thread and core ticket.
  • A Pull Request bringing aXe accessibility e2e testing in the Gutenberg repository has been created. The folks at Deque published a blog post about their takeaways.

Node 10.x LTS

The new versions of Gutenberg packages now require Node 10 or newer. This is to align with our stated support to follow the LTS release cycle of Node.

ESlint Package

The first version of the @wordpress/eslint-plugin package including recommended WordPress ESLint configuration has been published. A post detailing all the guidelines bundled in this package has been shared.

Action items:

  • Clarify in the docs and the package.json that the package requires eslint-plugin-react, eslint-plugin-jsx-a11y and eslint as peer dependencies.

JavaScript Documentation effort

There is an agreement that we need a bigger documentation effort to clarify some misunderstanding about the internals of Gutenberg.

Related:

  • If you have some technical knowledge and are interested in helping the documentation efforts, please have a look at this call for contributors.
  • Yoast is working on some extensibility APIs docs.

Documentation will be discussed further on the next meeting.

Open floor

#core-js, #javascript #summary

Proposed Revisions to JavaScript Coding Standards

Coding standards have been a recurring topic during the JavaScript Weekly Chats, most recently in the December 4th, November 27th, July 31st, July 24th, and July 17th meetings.

As a result of these conversations and in the observed emergence of patterns during the development of Gutenberg, a number of revisions to the JavaScript Coding Standards have been considered for proposal. This post serves as an outline of these proposals, presented here for wider consideration.

These proposed changes do not intend to serve as a radical departure in style, but rather to clarify ambiguities, resolve inconsistencies, and reduce the number of exceptions present in the standards.

You can try these coding standards using the newly-published ESLint configurations . Note that the ESLint plugin requires ESLint v5 or later, and eslint-plugin-reactand eslint-plugin-jsx-a11y must be installed in your development environment. Refer to the ESLint User Guide for more information.

Comments

Proposed Change: The use of /* for multi-line comments is not prescribed; it is now acceptable to use // for multi-line comments. An additional note about JSDoc /** should be included and refer the reader to the JavaScript Documentation Standards.

Before:

Single line comments:

someStatement();

// Explanation of something complex on the next line
$( 'p' ).doSomething();

Multi-line comments should be used for long comments, see also the JavaScript Documentation Standards:

/*
 * This is a comment that is long enough to warrant being stretched
 * over the span of multiple lines.
 */

After:

someStatement();

// Explanation of something complex on the next line
$( 'p' ).doSomething();

// This is a comment that is long enough to warrant being stretched
// over the span of multiple lines.

JSDoc comments should use the /** multi-line comment opening. Refer to the JavaScript Documentation Standards for more information.

Spacing

Proposed Change: Remove all spacing exceptions for object and array property access. This is a further iteration upon a previous revision which had removed exceptions for function arguments.

Before:

Always include extra spaces around elements and arguments:

array = [ a, b ];

foo( arg );

foo( 'string', object );

foo( options, object[ property ] );

foo( node, 'property', 2 );

Exceptions:

// For consistency with our PHP standards, do not include a space around
// string literals or integers used as key values in array notation:
prop = object['default'];
firstArrayElement = arr[0];

After:

Always include extra spaces around elements and arguments:

array = [ a, b ];

foo( arg );

foo( 'string', object );

foo( options, object[ property ] );

foo( node, 'property', 2 );

prop = object[ 'default' ];

firstArrayElement = arr[ 0 ];

“Yoda” Conditions

Proposed Change: This guideline will be removed from the coding standards. While it is still an option for developers to use this pattern, it will not be enforced one way or the other.

Before:

“Yoda” Conditions

For consistency with the PHP code standards, whenever you are comparing an object to a string, boolean, integer, or other constant or literal, the variable should always be put on the right hand side, and the constant or literal put on the left.

if ( true === myCondition ) {
// Do stuff
}

“A little bizarre, it is, to read. Get used to it, you will.”

After:

(N/A – The section is to be removed)

Equality

Proposed Change: There will be no exceptions for using strict equality === operator. The previous exception for == null comparison should be avoided, preferring in its place the equivalent strict equality comparisons on === undefined and === null.

Before:

Strict equality checks (===) must be used in favor of abstract equality checks (==). The only exception is when checking for both undefined and null by way of null.

After:

Strict equality checks (===) must be used in favor of abstract equality checks (==).

Multi-Line Conditions

Proposed Change: If a condition is short enough to fit in a line, it should be occupy a single line. Otherwise, the condition should be split one-per-line, with the opening and closing parentheses each on their own lines.

Before:

When a conditional is too long to fit on one line, successive lines must be indented one extra level to distinguish them from the body.

if ( firstCondition() && secondCondition() &&
		thirdCondition() ) {
	doStuff();
}

After:

When a conditional is too long to fit on one line, each operand of a logical operator in the boolean expression must appear on its own line, indented one extra level from the opening and closing parentheses.

if (
	firstCondition() &&
	secondCondition() &&
	thirdCondition()
) {
	doStuff();
}

Naming Conventions

Proposed Change: The additional naming conventions adopted into Gutenberg will be inherited into the WordPress JavaScript Coding Standards.

Namely, this includes additional consideration for:

  • Abbreviations and acronyms
  • Class construct (and @wordpress/element Components)
  • Constants

Before:

Variable and function names should be full words, using camel case with a lowercase first letter. This is an area where this standard differs from the WordPress PHP coding standards.

Constructors intended for use with new should have a capital first letter (UpperCamelCase).

Names should be descriptive, but not excessively so. Exceptions are allowed for iterators, such as the use of i to represent the index in a loop.

After:

Variable and function names should be full words, using camel case with a lowercase first letter. This is an area where this standard differs from the WordPress PHP coding standards.

Names should be descriptive, but not excessively so. Exceptions are allowed for iterators, such as the use of i to represent the index in a loop.

Abbreviations and Acronyms

Abbreviations must be written as camel case, with an initial capitalized letter followed by lowercase letters.

Acronyms must be written with each of its composing letters capitalized. This is intended to reflect that each letter of the acronym is a proper word in its expanded form.

If an abbreviation or an acronym occurs at the start of a variable name, it must be written to respect the camelcase naming rules covering the first letter of a variable or class definition. For variable assignment, this means writing the abbreviation entirely as lowercase. For class definitions, its initial letter should be capitalized.

// "Id" is an abbreviation of "Identifier":
const userId = 1;

// "DOM" is an acronym of "Document Object Model":
const currentDOMDocument = window.document;

// Acronyms and abbreviations at the start of a variable name are consistent
// with camelcase rules covering the first letter of a variable or class.
const domDocument = window.document;
class DOMDocument {}
class IdCollection {}

Class Definitions

Constructors intended for use with new should have a capital first letter (UpperCamelCase).

A class definition must use the UpperCamelCase convention, regardless of whether it is intended to be used with new construction.

class Earth {
	static addHuman( human ) {
		Earth.humans.push( human );
	}

	static getHumans() {
		return Earth.humans;
	}
}

Earth.humans = [];

All @wordpress/element Components, including stateless function components, should be named using Class Definition naming rules, both for consistency and to reflect the fact that a component may need to be transitioned from a function to a class without breaking compatibility.

Constants

An exception to camel case is made for constant values which are never intended to be reassigned or mutated. Such variables must use the SCREAMING_SNAKE_CASE convention.

In almost all cases, a constant should be defined in the top-most scope of a file. It is important to note that JavaScript’s const assignment is conceptually more limited than what is implied here, where a value assigned by const in JavaScript can in-fact be mutated, and is only protected against reassignment. A constant as defined in these coding guidelines applies only to values which are expected to never change, and is a strategy for developers to communicate intent moreso than it is a technical restriction.

Trailing Commas

Proposed Change: Trailing commas are to be enforced for arrays and objects whose members are enumerated across multiple lines. This should be incorporated into existing sections for “Objects” and “Arrays”.

Before:

Objects

Object declarations can be made on a single line if they are short (remember the line length guidelines). When an object declaration is too long to fit on one line, there must be one property per line. Property names only need to be quoted if they are reserved words or contain special characters:
// Preferred
var map = {
	ready: 9,
	when: 4,
	'you are': 15
};

// Acceptable for small objects
var map = { ready: 9, when: 4, 'you are': 15 };

// Bad
var map = { ready: 9,
	when: 4, 'you are': 15 };

After:

Object and Array Members

Objects and arrays can be declared on a single line if they are short (remember the line length guidelines). When an object or array is too long to fit on one line, each member must be placed on its own line and each line ended by a comma.

Object property names only need to be quoted if they are reserved words or contain special characters:

// Preferred
var obj = {
	ready: 9,
	when: 4,
	'you are': 15,
};
var arr = [
	9,
	4,
	15,
];

// Acceptable for small objects and arrays
var obj = { ready: 9, when: 4, 'you are': 15 };
var arr = [ 9, 4, 15 ];

// Bad
var obj = { ready: 9,
	when: 4, 'you are': 15 };
var arr = [ 9,
	4, 15 ];

Assignments and Globals

Proposed Change: For code written in ES2015+ using const and let, additional guidelines should be included to reflect differences in block scoping semantics. A new section “Declaring Variables with const and let” should be added before “Declaring Variables with var“.

After:

Declaring Variables with const and let

For code written using ES2015 or newer, const and let should always be used in place of var. A declaration should use const unless its value will be reassigned, in which case let is appropriate.

Unlike var, it is not necessary to declare all variables at the top of a function.

#javascript

JavaScript Packages and Interoperability in 5.0 and Beyond

WordPress 5.0 adds a number of new bundled script handles, including many specific to the new editor, as well as a few vendor dependencies. Given that a plugin or theme may already have registered their own copies of these same dependencies, this post is meant to serve as a reference for maximum interoperability. These are tips which could apply for any new dependency added by WordPress in any version, but are more likely than usual to be encountered given the amount of new JavaScript included starting in 5.0.

WordPress-Specific Scripts

All new WordPress-specific JavaScript code is registered using wp- as a prefix for the script handle. These include the following script handles:

  • wp-a11y
  • wp-annotations
  • wp-api-fetch
  • wp-autop
  • wp-blob
  • wp-block-library
  • wp-block-serialization-default-parser
  • wp-blocks
  • wp-components
  • wp-compose
  • wp-core-data
  • wp-data
  • wp-date
  • wp-deprecated
  • wp-dom-ready
  • wp-dom
  • wp-edit-post
  • wp-editor
  • wp-element
  • wp-escape-html
  • wp-format-library
  • wp-hooks
  • wp-html-entities
  • wp-i18n
  • wp-is-shallow-equal
  • wp-keycodes
  • wp-list-reusable-blocks
  • wp-notices
  • wp-nux
  • wp-plugins
  • wp-polyfill-element-closest
  • wp-polyfill-fetch
  • wp-polyfill-formdata
  • wp-polyfill-node-contains
  • wp-polyfill
  • wp-redux-routine
  • wp-rich-text
  • wp-shortcode
  • wp-token-list
  • wp-url
  • wp-viewport
  • wp-wordcount

Documentation for these packages can be found in the Gutenberg Handbook. They are also available for consumption via npm under the @wordpress scope (excluding polyfills).

Each WordPress package above assigns itself to the global scope under the wp namespace. For example, if your theme or plugin enqueues wp-editor, it will be made available at window.wp.editor in your browser. Conversely, you should also make sure that, for any JavaScript in your plugin which references a wp-namespaced library, the associated script handle is defined as a dependency of your script using the third argument of wp_enqueue_script and wp_register_script.

Vendor Dependencies

The following vendor dependencies have been added in WordPress 5.0:

For vendor scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

In general, a plugin should seek to avoid naming collisions by following the best practice of “Prefix Everything” as prescribed in the Plugin Handbook. While this can sometimes result in multiple copies of a script being present in a page, it reduces the chance for breakage and grants WordPress the option to use the unprefixed name in the future.

For dependencies which assign themselves to the global window scope, wp_add_inline_script can be used to ensure it is assigned to a global name unique to your plugin or theme. For example, the following snippet demonstrates including React on a page for a plugin without interfering with a core-enqueued copy of React, whether or not it exists:

wp_enqueue_script( 'myplugin-react', 'https://unpkg.com/react@16.6.0/umd/react.production.min.js' );
wp_add_inline_script( 'myplugin-react', 'window._originalReact = window.React;', 'before' );
wp_add_inline_script( 'myplugin-react', 'window.mypluginReact = window.React; window.React = window._originalReact;' );

With the above snippet, your intended copy of React will be guaranteed to be available at window.mypluginReact . This pattern can be applied to any vendor dependency to ensure compatibility with libraries added to WordPress in the future.

If your plugin or theme registers a script with using one of the above script handles as its registered name, consider taking one of the following steps:

Depending on whether you plan to continue support for versions of WordPress earlier than 5.0…

  • If you are only intending to target 5.0 and newer, verify compatibility between the versions of the library and simply remove your plugin or theme’s registration of the conflicting script handle.
  • If earlier version support is needed, and assuming your script registration occurs after the default scripts are registered (after wp_default_scripts), check for whether the script handle is already registered , then register or enqueue your copy of the script, optionally deregistering the core-registered script. Note that since core code targets a specific version of the vendor dependency, deregistering the script may have adverse effects on screens where it is used (notably the new editor screen).
    • Alternatively, follow the pattern as described above to assign your plugin’s copy of the library to a unique name.

Lodash Global

By default, Lodash will assign itself on the global scope using the _ name. Since WordPress will continue to bundle Underscore for the foreseeable future (see #43733), the core-registered Lodash adopts an approach similar to the enqueuing of jQuery to avoid naming conflicts. It does so using Lodash’s _.noConflict, assigning Lodash to the global scope as window.lodash

For this reason, if your plugin or theme uses Lodash as a dependency, you should make sure to not cause _.noConflict to be called multiple times in conflict with the core-registered script.

  • When using the copy of Lodash registered by core, your code should reference it by the window.lodash global.
  • When enqueuing your own copy of Lodash, you should only call Lodash’s _.noConflict under the condition that window.lodash is not already assigned and that the core-registered Lodash will not be included on the page.

In general, the _ global should be used only to reference Underscore.

React and wp-element

When extending the new editor interface, you should use the new wp-element script handle, rather than React directly. The element package is a thin abstraction over the React interface, and implements most all of the same functionality. Targeting wp-element will ensure the greatest compatibility for your plugin as new versions of WordPress are released.

Refer to the wp-element package documentation and React website for more information. 

#5-0, #dev-notes, #javascript

Javascript Chat Summary – December 4, 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: Holiday / WCUS scheduling

Slack Conversation

We agreed to cancel the #core-js meetings for December 11th (post-WCUS travel), December 25th (Christmas), and January 1st (New year). @aduth posted a cancellation notice here: https://make.wordpress.org/core/2018/12/04/javascript-weekly-chats-wordcamp-us-holiday-scheduling/

Agenda: Linting

Slack Conversation

A PR which extracts Gutenberg’s ESlint config to its own package by @gziolo has been merged. It’s set to be published to NPM as @wordpress/eslint-config. Publication is currently blocked by the 5.0 RC freeze, but is expected to land around contributor day together with a post outlining revisions to the JavaScript coding standards prepared by @aduth

We also discussed how to manage custom eslint rules. Some linting rules might not be useful outside of the context of WordPress core or Gutenberg. We decided for now to go the same path as the Jest eslint package. For the time being we will have one package with multiple configs, which will allow consumers to select the configs they need. 

Agenda: 5.0 Script Changes

Slack Conversation

With WordPress 5.0, a few vendor scripts (like lodash) are being included in core. For these scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

Different approaches to prevent this were discussed. @aduth is working on a devnote to help integrators prevent these kinds of conflicts from happening.

#javascript, #meeting-notes #summary

JavaScript Weekly Chats – WordCamp US & Holiday Scheduling

As discussed in today’s chat, the following meeting dates for the JavaScript Weekly Chat will be cancelled due to WordCamp US travel and in observation of upcoming holidays:

  • December 11
  • December 25
  • January 1

#javascript