fix!: replace uuid dependency with crypto.randomUUID()

[escoberik]

Problem

uuid ^7.0.3 is flagged by GHSA-w5hq-g745-h8pq — a missing buffer bounds check in uuid.v3/v5/v6() when an explicit buf argument is provided. The advisory marks all versions below uuid@14.0.0 as vulnerable, so downstream consumers (notably the Expo SDK and any project using @expo/config-plugins) see security audit failures they cannot resolve.

The "fix" suggested by npm audit — upgrading to uuid@14 — isn't viable here because uuid v14 dropped CommonJS support, and this package uses require('uuid').

Solution

This PR replaces the single uuid.v4() call in generateUuid() with Node's built-in crypto.randomUUID(), which:

• Produces the same RFC 4122 v4 UUID format
• Has been available since Node.js 14.17.0 (LTS)
• Requires no external dependency

The uuid package is removed from dependencies entirely. The engines field is updated from >=10.0.0 to >=14.17.0 to reflect the new minimum.

Testing

All 426 existing tests pass with no changes to the test suite.

ℹ pass 426
ℹ fail 0

[breautek]

Thanks for the PR. I'm always in favour of replacing third-party dependencies with core nodejs libraries whenever possible and this does just that.

Just a few notes, in addition to review lines.

1. I think a separate PR should be made for the engine bump. This PR can then reference the other PR as a dependency. This is purely to facilitate reverts, if we for some reason require to, though I doubt it will happen.
2. I think this PR should be marked as a breaking change. The commit message should be fix!: ..., the ! indicating a breaking change. The PR message should provide a small blurb how the PR is a breaking change, which I think you already have.

[breautek]

Can you revert this change back to >=10.0.0

I know this change requires 14.17.0 but that change should be in it's own PR so that the engine bump can be independent of the UUID change -- should we find a reason to revert the UUID change.

[breautek]

can you hoist the crypto require up with the other requires?

generateUuid is something that I believe is triggered often and while modules are cached and executed once for the first require, hoisting an access variable just allows it to skip the cache-lookup each time this function is invoked.

[escoberik]

Oh, sorry. My bad.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.91%. Comparing base (b27fbd4) to head (b9f82b7).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #153      +/-   ##
==========================================
- Coverage   96.91%   96.91%   -0.01%     
==========================================
  Files          51       51              
  Lines       11125    11124       -1     
==========================================
- Hits        10782    10781       -1     
  Misses        343      343              

☔ 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.