[ntsekouras]

What?

Follow up of: #81478

Older @wordpress/dataviews versions published to npm call the private APIs opt-in at module load, so plugins bundling one of those copies (e.g. Jetpack Publicize, the WordPress AI plugin) throw with 23.9.0-rc.1.

This PR adds the allowlist entry back. I'm not sure if we can define a strategy about removing such entries and when, but it feels to me as a better step to add it back for now and avoid lots of possible breakages.

This should be cherry-picked in the 23.9 release.

Testing Instructions

1. Install a plugin that bundles an older @wordpress/dataviews version (Jetpack with Publicize enabled is one).
2. Open the post editor. Without this PR the Jetpack sidebar is missing and the console shows the "You tried to opt-in to unstable APIs" error. With this PR it works again.

Use of AI Tools

Generated with Fable 5 and reviewed/adjusted manually.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +2 B (0%)

Total Size: 7.92 MB

📦 View Changed

Filename	Size	Change
build/scripts/private-apis/index.min.js	1.15 kB	+2 B (+0.17%)

_{compressed-size-action}

[oandregal]

I guess for bundled packages (consumers can use any version of it), we can really only remove this after a long time (say two major WordPress versions?).

How should we go about this? How do we "schedule" a task for removal in two major WP versions? Ideally, we should be able to communicate this to consumers (e.g., via deprecate warning or something similar). Do we add a "deprecate" allow list that still works but throws a warning?

[oandregal]

#82231 explores adding deprecated support to the private API package.

[oandregal]

I'm running the cherry-pick task.

[oandregal]

I just cherry-picked this PR to the release/23.9 branch to get it included in the next release: 5edcac3

[aduth]

While this prevents the error when calling unlock, I wonder if it's still going to be an issue where older bundled copies are looking for specific private APIs that have been removed in newer versions (i.e. the private APIs removed in #81230). Updating to use the /wp entrypoint could help here, as would updating to newer versions of DataViews, but this still requires downstream action.

[ciampo]

I wonder if it's still going to be an issue where older bundled copies are looking for specific private APIs that have been removed in newer versions (i.e. the private APIs removed in #81230).

Potentially yes. I commented about the potential need for such compat feature in #81230 (comment)