chore(deps): bump uuid to v10 across affected packages#2815
Conversation
Supersedes the five dependabot PRs targeting uuid v14 (#2807, #2806, #2805, #2789, #2788). uuid v14 (and v11+) is ESM-only and would have required an ESM migration of every consumer; v10 is the highest version that still ships dual CJS+ESM exports, satisfying the security driver without forcing a module-system change. - firestore-counter/functions: ^3.3.2 -> ^10.0.0 - firestore-counter/clients/node: ^8.3.2 -> ^10.0.0 - firestore-counter/clients/web: ^3.3.2 -> ^10.0.0 (also @types/uuid) - storage-resize-images/functions: ^11.0.5 -> ^10.0.0, drop the duplicate `uuidv4` legacy package and migrate resize-image.ts to import { v4 as uuidv4 } from "uuid" to match util.ts and file-operations.ts.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the uuid dependency to version 10 across multiple packages and migrates the image resizing function from uuidv4 to the standard uuid library. Feedback from the reviewer highlights that uuid version 10 is deprecated and suggests upgrading to version 11.1.0 or higher, which maintains CommonJS compatibility while ensuring long-term support. It was also recommended to remove the now-redundant @types/uuid package.
| "@types/uuid": "^10.0.0", | ||
| "uuid": "^10.0.0" |
There was a problem hiding this comment.
Since uuid version 9 and above includes built-in TypeScript definitions, the @types/uuid package is redundant and can be removed. Additionally, as uuid version 11.1.0+ supports CommonJS and version 10 is now marked as unsupported, it is recommended to upgrade directly to ^11.1.0.
"uuid": "^11.1.0"Per review on #2815: uuid v10 was deprecated upstream ("uuid@10 and below is no longer supported"). v11.1.0 is the correct CJS-compatible target — it ships dual CJS+ESM exports via the package's `exports` field. v12+ drops CJS again, so v11 is the only currently-supported CJS-capable line. - firestore-counter/{functions,clients/node,clients/web}: ^10.0.0 -> ^11.1.0 - storage-resize-images/functions: ^10.0.0 -> ^11.1.0 - firestore-counter/clients/web: drop now-redundant @types/uuid (uuid ships its own types from v9+)
|
Validated @gemini-code-assist's feedback against npm registry data and pushed an amendment retargeting to Verified directly from the registry (
So my original analysis was wrong on two points:
That makes v11 the only currently-supported CJS-capable line. The storage-resize-images pin to Also dropped Builds clean across all four packages with v11.1.1 resolved; webpack picks up |
|
Thank you for the thorough investigation and for validating the |
2 participants
Summary
Supersedes five stale dependabot PRs that all attempted to bump
uuidto v14:uuid v14 (and v12+) is ESM-only and drops CJS exports. Every consumer in this repo compiles to CJS (
tsconfig.module: "commonjs", no"type": "module"in any package.json), so the dependabot bumps would have broken every callsite without a tsconfig + import-style refactor.uuid v11 is the only currently-supported CJS-capable line. v10 is deprecated upstream ("uuid@10 and below is no longer supported"); v12+ dropped CJS again. v11.1.0+ ships dual CJS+ESM exports via the
exportsfield.Changes
firestore-counter/functions:uuid^3.3.2->^11.1.0firestore-counter/clients/node:uuid^8.3.2->^11.1.0firestore-counter/clients/web:uuid^3.3.2->^11.1.0, dropped now-redundant@types/uuid(uuid ships its own types from v9+)storage-resize-images/functions:uuid^11.0.5->^11.1.0(minor)uuidv4legacy packagesrc/resize-image.tstoimport { v4 as uuidv4 } from "uuid", matchingutil.tsandfile-operations.tsalready in the same packageNo tsconfig changes, no module-system changes, no webpack changes.
Test plan
npm run buildclean in firestore-counter/functionsnpm run build(webpack) clean in firestore-counter/clients/web (uuid resolved fromuuid/dist/cjs-browser)npm run buildclean in storage-resize-images/functionsnpm testin storage-resize-images/functions: 49 unit tests pass; 4 e2e failures are pre-existing emulator-connect issues (ECONNREFUSED 127.0.0.1:9199) unrelated to this change