Improve pre-flight npm access checks - #80334

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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @myexampl35-dotcom.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: myexampl35-dotcom.

Co-authored-by: desrosj <desrosj@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>

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

Size Change: 0 B

Total Size: 7.76 MB

_{compressed-size-action}

OK, I'm a bit curious how long it will take to run npm access in loop for 140 packages 🙂

That did come to mind. 😅

I ran some testing locally. Across 50 runs of npm access list collaborators @wordpress/block-library the mean time was 1.008s and median time was 0.937s. Just 15 of those 50 requests requests took longer 1 second. So this would add ~2-2.5 minutes to the pre-flight steps.

Another option is to check only the first package, or maybe the first 5 if there's a desire to validate multiple packages. I'm curious what @ciampo prefers given he can speak best to the original intention of these pre-flight checks.

Flaky tests detected in 68ae21e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29447226898
📝 Reported issues:

• [Flaky Test] should cut and paste individual blocks with collapsed selection #80248 in /test/e2e/specs/editor/various/copy-cut-paste.spec.js

As also mentioned in Slack, we could drop the npm access check and only keep npm whoami, as it's sufficient to catch invalid/expired/misconfigured credentials.

The npm access command also kind of contradicts the fact that we pass --no-verify-access  when running lerna.

We can keep the npm whoami and the npm view [package]@[version] checks

My preference would be to just check npm whoami. That catches practically all realistic issues that can happen with the token. One step further would be to list collaborators for one @wordpress/* package. That catches an unlikely token that was wrongly issued from the start, with insufficient permissions.

I implemented the npm whoami suggestion and will merge this now: the old npm access command interrupted the 23.7 RC 1 release earlier today.

Thanks @jsnajdr! No objections here.

I just cherry-picked this PR to the release/23.7 branch to get it included in the next release: de2e2d7