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