JavaScript Chat Summary – September 4th

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: Deprecation policy

Slack Conversation

Gutenberg has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin developers to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.

It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:

  • Packages follow semver, so something could be removed in a major version, ie. 3.0
  • Then the package adds a deprecation warning in a minor version before that, ie. 2.x
  • The deprecated call as used by packages wouldn’t include anything specific about Gutenberg, but somehow Gutenberg extends the message it logs (by filter), analyzes the generic deprecation version (the npm SemVer) and maps it back to an equivalent Gutenberg / WordPress release.

Actions

  • Explore extensibility of deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)
  • (Re-)consider how and where to define boundaries between packages and core-specific JavaScript (proposal by @atimmer, @omarreiss)

Open floor: Also allow building in src

Slack Conversation

The build step that was introduced in #43055 seems to cause quite some friction for PHP development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.

It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.

Actions

@omarreiss will work on a patch.

Open floor: Guidelines for including WP packages

Slack Conversation

Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:

  • if the plugin author needs to backport these API’s or not in order to support classic editor.
  • If the plugin author uses ES2015 or older versions of JS.
  • If the plugin author uses a build proces.

Actions

@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.