DataViews: Add a lint rule preventing private API imports

[ntsekouras]

What?

Part of: #81230

This PR adds a lint rule so that private API usage can't creep back into DataViews once the cleanup is done.

Note that this is a placeholder PR: CI is expected to be red until all the remaining private imports are gone.

Testing Instructions

1. After the removal of all private API imports in dataviews(and rebasing) the CI should be 🟢

[github-actions]

Size Change: -5 B (0%)

Total Size: 7.91 MB

📦 View Changed

Filename	Size	Change
build/scripts/private-apis/index.min.js	1.16 kB	-5 B (-0.43%)

_{compressed-size-action}

[jorgefilipecosta]

LGTM 👍 The CI failure is a good proof it is working as expected, it should be merged when we finish the refactor in progress.

[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: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: aduth <aduth@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.

[aduth]

Not a blocker, but ideally we'd expand this to apply to any bundled package, because the reason we're forbidding private APIs in @wordpress/dataviews extends to any bundled package. We could determine this by checking wpScript and wpScriptModule fields.

[oandregal]

Every private API has been removed, and this is free to land.

[ntsekouras]

Not a blocker, but ideally we'd expand this to apply to any bundled package, because the reason we're forbidding private APIs in @wordpress/dataviews extends to any bundled package. We could determine this by checking wpScript and wpScriptModule fields.

@aduth that's a good idea, but let's handle in a follow up.

[youknowriad]

If I'm not wrong this only catches direct usage. It doesn't prevent importing a component from say "components" that uses private APIs. We don't want these either.

[ntsekouras]

If I'm not wrong this only catches direct usage. It doesn't prevent importing a component from say "components" that uses private APIs. We don't want these either.

That's right. I'm preparing a follow up (per @aduth's comment above) to apply the restriction to all bundled packages, so a bundled package can't pull private APIs through another bundled one either. The rule only blocks new usages, but for dataviews the only existing one is the ThemeProvider compat fallback in ui, which gets removed in 7.3 anyway.

For components (and every externalized package) I think we're okay on the main entry, since plugins get the externalized wp.components.

So the gap seems to be the /wp entry that inlines everything, but is it something we aim to remove now with #81230 closed?

--- edit

The follow up PR is here.

[youknowriad]

My question was not about "bundled" packages. What we want is to prevent dataviews from importing a component in components package that make use of a private API as well.

[ntsekouras]

Maybe a CI job could handle this? We could bundle dataviews from its entry with the package sources inlined and fail if @wordpress/private-apis ends up in the graph? 🤔

I opened a draft PR to see if that's close to what you had in mind. I'm still not sure how we should handle the ThemeProvider case though (see that PR's description).

[youknowriad]

Maybe a CI job could handle this? We could bundle dataviews from its entry with the package sources inlined and fail if @wordpress/private-apis ends up in the graph? 🤔

Yep sounds smart. indeed 👍 and yes we can do that for all bundled packages.

[aduth]

@manzoorwanijk has some experience as well with checking how dependencies surface in runtime outputs via his work in #79094, in case there's any overlap in how we can audit dependency use in built artifacts.

[manzoorwanijk]

The approach in #82027 looks fine to me. I added some suggestions for further improvments.

[aduth]

Heads-up that removing from the private-apis allowlist is having some impact in downstream plugins that are still bundling older versions of @wordpress/dataviews, as the old copy still tries to operate on private APIs that are now forbidden in newer versions of Gutenberg.

Example: WordPress/ai#984

[youknowriad]

It looks like a lot of folks might not be using the "/wp" package (See #82202) Maybe there's some mitigation we could be doing.

[oandregal]

The private API removal was reverted at #82221 and backported to Gutenberg 23.9