Summary
[email protected] declares "google-auth-library": "10.5.0" — an exact version with no caret. The previous release, 8.0.1, used "^10.1.0". This prevents google-auth-library from deduplicating for any consumer that also depends on a newer google-auth-library directly, installing two copies.
Where it changed
The caret was dropped in the monorepo migration commit 36277d77 (PR #7606, "chore: google cloud node core migration"), which bulk-pinned sibling cross-dependencies to exact versions across core/packages/*. nodejs-googleapis-common was one of several affected — gaxios, gcp-metadata, etc. got the same treatment.
Current source: core/packages/nodejs-googleapis-common/package.json still shows "google-auth-library": "10.5.0".
Why it's a problem
The pin is already stale — the same monorepo ships [email protected]. A consumer that depends on google-auth-library@^10.7.0 directly and on googleapis (which pulls googleapis-common@^8.0.0 → 8.0.2) ends up with both 10.5.0 and 10.7.0 installed. In TypeScript this breaks compilation, because the two OAuth2Client classes are structurally incompatible (each declares a private redirectUri):
error TS2322: Type 'OAuth2Client' ([email protected]) is not assignable to
type 'OAuth2Client' ([email protected]).
Types have separate declarations of a private property 'redirectUri'.
Repro
A package depending on googleapis@^173 and google-auth-library@^10.7.0, type-checking any use of google.auth.OAuth2 against google.drive(...).
Note
8.0.2 has no source changes vs 8.0.1 (no commits touched the package src/ between the two releases) — it appears to be a dependency-repinning/version-bump release, so the exact pin looks like an unintended artifact of the migration tooling rather than a deliberate constraint.
Expected
Restore a caret range for google-auth-library (e.g. ^10.1.0 or ^10.7.0) in googleapis-common, and ideally across the other siblings repinned in #7606.
Summary
[email protected]declares"google-auth-library": "10.5.0"— an exact version with no caret. The previous release,8.0.1, used"^10.1.0". This preventsgoogle-auth-libraryfrom deduplicating for any consumer that also depends on a newergoogle-auth-librarydirectly, installing two copies.Where it changed
The caret was dropped in the monorepo migration commit
36277d77(PR #7606, "chore: google cloud node core migration"), which bulk-pinned sibling cross-dependencies to exact versions acrosscore/packages/*.nodejs-googleapis-commonwas one of several affected —gaxios,gcp-metadata, etc. got the same treatment.Current source:
core/packages/nodejs-googleapis-common/package.jsonstill shows"google-auth-library": "10.5.0".Why it's a problem
The pin is already stale — the same monorepo ships
[email protected]. A consumer that depends ongoogle-auth-library@^10.7.0directly and ongoogleapis(which pullsgoogleapis-common@^8.0.0→8.0.2) ends up with both10.5.0and10.7.0installed. In TypeScript this breaks compilation, because the twoOAuth2Clientclasses are structurally incompatible (each declares aprivate redirectUri):Repro
A package depending on
googleapis@^173andgoogle-auth-library@^10.7.0, type-checking any use ofgoogle.auth.OAuth2againstgoogle.drive(...).Note
8.0.2has no source changes vs8.0.1(no commits touched the packagesrc/between the two releases) — it appears to be a dependency-repinning/version-bump release, so the exact pin looks like an unintended artifact of the migration tooling rather than a deliberate constraint.Expected
Restore a caret range for
google-auth-library(e.g.^10.1.0or^10.7.0) ingoogleapis-common, and ideally across the other siblings repinned in #7606.