JavaScript Chat Summary, February 26th, 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.

Progress Updates

Slack Conversation

@greatislander finished adding repository.directory fields for each published package, and opened an upstream pull request to the npm-package-json-lint project so that can better enforce this for new packages introduced in the future.

@gziolo and @nosolosw completed work on extracting a reusable Webpack configuration which can be used by developers (e.g. plugin authors) to easily adopt a Gutenberg build workflow into their own projects. @nosolosw mentioned that work continues to use this configuration as the default when running wp scripts build if no explicit configuration is provided.

Package Releases Feedback and Enhancements

Slack Conversation

@youknowriad shared a summary of the current workflow for publishing npm packages, the shortcomings therein, and proposed a revision to the workflow which better supports more regular publishing accommodating WordPress minor releases.

I propose we update our workflow to the following: (assuming the version number of the packages are major.minor.patch)
– Rename the current g-minor branch (the branch from which the npm releases are made) to wp/trunk
– Every time a new plugin version is released (using our current plugin release workflow), merge this version into wp/trunk, do an npm package release by bumping at least the « minor » version number (or major but not patch)
– Every time, the WordPress SVN trunk is branched (to create WordPress 5.1, WordPess 5.2… branches) — this happens in general when the WordPress major RC version is created —, create a corresponding wp/5.1, wp/5.2 etc… in Github based on wp/trunk.
– This wp/x.x branch will serve to release package releases used in Minor and security versions of WordPress. All package releases happening from these branches will bump only the patch version number of the package.


Special cases:
– Sometimes WordPress trunk is closed (in general it last 2 to 3 weeks) between beta and RC. During this period, we’ll have a Gutenberg plugin release that is not going to be released as npm packages directly until WordPress trunk is open again.
– For previous WordPress versions that contain packages (5.0 and 5.1) we didn’t have enough room for package version upgrades for security and patch versions that might be needed in the future. For these particular cases, we’ll use the « build metadata » version modifier supported by npm. Example 1.2.4+sec.1

Discussion followed this proposal, clarifying details of the revised workflow. There was general consensus that the proposal was agreeable.

As a next step, @youknowriad plans to open a pull request proposing revisions to the current release workflow document.

Open Floor

Slack Conversation

@greatislander requested an update on when the jest-puppeteer-axe package would be made broadly available, as its unavailability is a blocker to the accessibility team being able to implement front-end tests for themes. In mind of the above release workflow proposal revisions, it was suggested that it could be published this week if the workflow changes are adopted.

#core-js, #javascript