Skip to content

Replace npm info with package manager aware registry query - #2047

Closed
zbrydon wants to merge 3 commits into
changesets:mainfrom
zbrydon:replace-npm-info
Closed

Replace npm info with package manager aware registry query#2047
zbrydon wants to merge 3 commits into
changesets:mainfrom
zbrydon:replace-npm-info

Conversation

@zbrydon

@zbrydon zbrydon commented May 31, 2026

Copy link
Copy Markdown

Issue

Resolves #965

Problem

The getPackageInfo function in the publish command always uses npm info to query package metadata, regardless of which package manager the project is configured to use.

Projects can declare their package manager using either the packageManager field or the devEngines.packageManager field in package.json:

{
  "packageManager": "pnpm@10.12.1"
}
OR
{
  "devEngines": {
    "packageManager": {
      "name": "pnpm",
      "version": ">=10",
      "onFail": "error"
    }
  }
}

The devEngines field is an OpenJS Foundation standard for declaring package manager and runtime requirements during development.

Because npm info is always used, projects that rely on pnpm or Yarn-specific registry configuration and authentication may fail or behave incorrectly. Both pnpm and Yarn provide their own info commands that respect their configured registries and credentials.

The publish workflow should use the project's configured package manager when querying package metadata.

What changed

  • Added getInfoTool(cwd) to detect the project's package manager using detect({ cwd }) and map it to:

    • npm
    • pnpm
    • yarn-classic
    • yarn-berry

  • Updated getPackageInfo to use the appropriate package manager command:

    • npm / pnpm

      <pm> info <pkg> --registry=<url> --json

    • Yarn Berry

      yarn npm info <pkg> --json

      Registry configuration is read from .yarnrc.yml.

    • Yarn Classic

      yarn info <pkg> --registry=<url> --json

      Handles Yarn v1's { type: "inspect", data } response format and treats { type: "error" } as a package-not-found result.

  • Extended isEmptyResult to recognize Yarn Classic error responses, ensuring the existing two-query fallback and E404 normalization logic continue to work correctly.

  • Threaded cwd through:

    publishPackages
  → getUnpublishedPackages
    → infoAllow404
      → getPackageInfo

    so package manager detection always runs relative to the project root.

Testing

New unit tests cover:

  • pnpm: verify pnpm info is called instead of npm info
  • yarn classic error response: verify it is treated as "not found" and falls through to E404
  • yarn classic success response: verify the { type: "inspect", data } wrapper is stripped before returning

@changeset-bot

changeset-bot Bot commented May 31, 2026 •
edited
Loading

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 5b2c51a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@codecov

codecov Bot commented May 31, 2026 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.29730% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 84.18%. Comparing base (18e1661) to head (5b2c51a).

Files with missing lines Patch % Lines
...ckages/cli/src/commands/publish/publishPackages.ts 50.00% 1 Missing ⚠️
Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #2047      +/-   ##
==========================================
+ Coverage   83.85%   84.18%   +0.32%     
==========================================
  Files          56       56              
  Lines        2465     2491      +26     
  Branches      748      760      +12     
==========================================
+ Hits         2067     2097      +30     
+ Misses        392      388       -4     
  Partials        6        6

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@beeequeue

beeequeue commented Jun 1, 2026

Copy link
Copy Markdown
Member

thanks for the PR!

i have been considering rewriting the info fetching functionality to just use fetch to call the npm registry, as it should speed things up considerably to not have to start new processes for each call.

however that would require us being able to know which registry to call for each package which is not the simplest thing...

@Andarist

Andarist commented Jun 1, 2026

Copy link
Copy Markdown
Member

i have been considering rewriting the info fetching functionality to just use fetch to call the npm registry,

I looked into this when working on #1845 and just gave up. We could do this but it would require us to reverse-engineer quite a bit around how the CLIs handle .npmrc and alikes

@beeequeue

beeequeue commented Jun 1, 2026

Copy link
Copy Markdown
Member

Sounds like something a new package could do...

@zbrydon

zbrydon commented Jun 3, 2026

Copy link
Copy Markdown
Author

thanks for the PR!

i have been considering rewriting the info fetching functionality to just use fetch to call the npm registry, as it should speed things up considerably to not have to start new processes for each call.

however that would require us being able to know which registry to call for each package which is not the simplest thing...

mhmmm true that would be miles nicer that what I've whacked together 😅

I wonder whether something like https://github.com/npm/npm-registry-fetch would solve the problem 🤔

This was referenced Jun 5, 2026
Closed
Merged
@Andarist

Andarist commented Jun 5, 2026

Copy link
Copy Markdown
Member

@zbrydon we plan to release v3 by the end of the month. I'm refactoring this stuff as we speak - and while it might not address everything yet... any further work should target that refactor. I'll open some PRs over the weekend and ping you for review/input.

@zbrydon zbrydon mentioned this pull request Jun 15, 2026
Merged
@Andarist

Andarist commented Jun 21, 2026

Copy link
Copy Markdown
Member

This is going to be superseded by #2097 where I'm working on a more holistic revamp of what package manager commands are invoked (and how).

@Andarist Andarist closed this Jun 21, 2026
samchungy added a commit to apollo-server-integrations/apollo-server-integration-koa that referenced this pull request Jun 28, 2026
@samchungy
go back to packageManager for now:
2acdb2a 
changesets/changesets#2047
samchungy added a commit to apollo-server-integrations/apollo-server-integration-koa that referenced this pull request Jun 28, 2026
@renovate @samchungy
chore(deps): update dependency node to v7 (#255)
1e406e7 
* chore(deps): update dependency node to v7

* go back to packageManager for now:

changesets/changesets#2047

---------

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Sam Chung <samchungy@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

yarn changeset publish is using npm info instead of yarn npm info

3 participants

@zbrydon @beeequeue @Andarist