Packages: Deprecated: Gutenberg-independent deprecations

[aduth]

Related: Discussed during September 4th JavaScript Chat

Currently, all calls to the deprecated function pass a Gutenberg version number at which the feature is to be deprecated. This is sensible within the context of the Gutenberg plugin, but has no meaning in the context of the published npm package.

This raises a few questions (action items denoted by ⚠️):

• Should npm package releases have a separate schedule for feature deprecation?
  • Currently: No
  • ✅ Operating assumption for intended ideal: No. Preferably, at least one minor version of the package with deprecated message is published (reference).
• Should npm packages log warnings including the Gutenberg deprecation version?
  • Currently: Yes
  • ⚠️Operating assumption for intended ideal: No. It's suggested that the message be made filterable, with no default Gutenberg references for the published deprecated module messaging. The Gutenberg references should be added by an extension via [???] (implementation undetermined)
• Should the public API interface of deprecated include plugin and version options?
  • Currently: Yes
  • ⚠️Operating assumption for intended ideal: Unknown. The plugin option is probably unnecessary, though it may be sensible to have some built-in knowledge / messaging of a deprecation removal version. In these cases, it may be required to allow granular extension of specific message fragments (e.g. the variables composing the deprecated message).

[paaljoachim]

I see a merged PR here so that I will close this old issue.

@gziolo (Greg I have been pinging you a lot to Andrew's older issues. I do hope that is alright.)

[gziolo]

It's less relevant as of today but we could change the package to print the Gutenberg plugin version only inside the plugin. It should be doable by using process.env.GUTENBERG_PHASE === 2 constant check in @wordpress/deprecated. On the other hand, it isn't quite a good match. I would say that it's fine to leave it closed.