JavaScript Chat Summary – June 26th

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Participants: @omarreiss, @aduth, @herregroen, @nerrad, @abdullahramzan, @azaozz, @adamsilverstein, @youknowriad

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

Sunsetting the Packages Repository

It’s been proposed that all modules published through NPM be moved from the WordPress/packages repository to the WordPress/gutenberg repository.

Motivations:

  • The packages setup is already duplicated in Gutenberg.
  • Some Gutenberg packages can’t be moved at the moment to the packages repository to avoid splitting the work between two different repositories.
  • Having a unique location to publish packages.
  • One less repository for WP.
  • Preparation for eventual merge to core.
  • Implies the potential of Gutenberg to be bigger than WordPress.
  • Helps process for making in-place updates to packages for Gutenberg use-cases without going through the tedious flow of Packages PR -> NPM publish -> Gutenberg PR.

Decision: It’s been agreed that packages are to be merged into the Gutenberg repository. @omarreiss has been volunteered to create a pull request which would preserve the commit history for packages in the transition.

An Alternative to wp.apiRequest

Problem: The current argument and return value signature of wp.apiRequest binds us to jQuery.

Proposal: Create a new, separate wp.fetch module as a replacement, based on the standard window.fetch browser API.

Decision: It’s been agreed to move forward with the new wp.fetch script and deprecate wp.apiRequest. Separately, an observation has been noted that all future work should avoid hard dependencies on third-party scripts.

Deprecation Strategy

(Continued from last week’s discussion)

Problem: How can we introduce breaking changes necessary for user benefit without sacrificing a commitment to backwards compatibility?

Options:

  • Create separate scripts and allow the originals to remain forever.
    • Downside: User impact in code size from loading many variations of the same sorts of scripts.
  • Communicate a strategy to move away from the deprecated feature, then remove the feature after a predefined amount of time.
    • Important that this is a well-defined timeframe, and communication is centralized.

Prior Art: Gutenberg’s Deprecated Features

Action Items:

  • Explore options for how communication and migrations can be assured, for both developers (visibility to the removals) and users (compatibility between plugins and future versions of WordPress).
  • Create a JavaScript-specific variant of the Deprecated Functions page.
  • Propose for discussion in a Core Dev meeting.

Data Module Improvements

There are two proposals by @youknowriad for major improvements to the data module:

Build Process

Feedback is requested on the following tickets:

  • #44371 – Make sure all JS globals are explicitly assigned to the window.
  • #43731 – Use Webpack + NPM scripts to build all the things

Progress has been made by @omarreiss on a new grunt build:dev command which symlinks the php files on systems that allow symlinking to make the PHP only workflow much smoother.

Inline Documentation

Reminder that the JSDocs Initiative could use your help to ensure that all JavaScript files in core are properly documented. This is a great way for new contributors to get involved and learn about WordPress’ JavaScript along the way.

Update: Documentation for six files have been committed since WordCamp Europe 2018.