chore: restore package-lock.json using omit-lockfile-registry-resolved#1132
Conversation
📝 WalkthroughWalkthroughThis PR updates CI and release automation to use npm cache-enabled setup-node steps and lockfile-based installs, while also changing repository npm settings and allowing package-lock.json to be tracked. ChangesCI Dependency Install and Lockfile Configuration
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![semgrepcode-auth0[bot]](https://avatars.githubusercontent.com/in/977730?s=60&v=4){kind=small}
| "dev": true, | ||
| "license": "MIT" | ||
| }, | ||
| "node_modules/axios": { |
There was a problem hiding this comment.
Risk: Affected versions of axios are vulnerable to Inefficient Regular Expression Complexity / Uncontrolled Resource Consumption. axios is vulnerable to a regular expression denial of service (ReDoS). The internal cookies.read() helper in lib/helpers/cookies.js builds a regular expression by concatenating the cookie name directly into the pattern without escaping regex metacharacters. When the cookie name flowing into the XSRF cookie read (e.g. via xsrfCookieName) contains a catastrophic-backtracking payload, evaluating the regex against document.cookie can freeze the JavaScript event loop, causing a denial of service in the browser tab or in Node.js/SSR applications. The affected code path is reached during ordinary axios request processing, so any importer of an affected version is exposed. Upgrade to a patched version (0.32.0 or 1.16.0), or set xsrfCookieName: null to disable XSRF cookie reading.
Manual Review Advice: A vulnerability from this advisory is reachable if you are using axios in browser with untrusted xsrfCookieName value
Fix: Upgrade this library to at least version 1.16.0 at auth0-react/package-lock.json:2881.
Reference(s): GHSA-hfxv-24rg-xrqf
🥳 Fixed in commit 7581d53 🥳
| "dev": true, | ||
| "license": "MIT" | ||
| }, | ||
| "node_modules/axios": { |
There was a problem hiding this comment.
Risk: Affected versions of axios are vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') / Unintended Proxy or Intermediary ('Confused Deputy'). axios reads config.proxy via prototype-chain property access, so any Object.prototype pollution elsewhere in the dependency tree silently routes all HTTP requests through an attacker-controlled proxy, yielding a full man-in-the-middle. The vulnerability fires on ordinary axios usage with no specific API call or configuration required; upgrade to axios 1.16.0 or later.
Manual Review Advice: A vulnerability from this advisory is reachable if you use axios to make HTTP requests
Fix: Upgrade this library to at least version 1.16.0 at auth0-react/package-lock.json:2881.
Reference(s): GHSA-35jp-ww65-95wh, GHSA-fvcv-3m26-pcqx, CVE-2026-44494
🍰 Fixed in commit 7581d53 🍰
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.npmrc (1)
2-2: 🚀 Performance & Scalability | 🔵 TrivialValid option; note the associated install-speed trade-off.
omit-lockfile-registry-resolvedis a legitimate npm config that strips theresolvedfield from registry deps in the lockfile. Per npm's own docs, this causes npm to re-fetch each package's manifest to resolve tarball URLs at install time, which can partially offset the speed gains expected from switching tonpm ci+cache: npmin this PR. Worth keeping in mind if CI install times increase.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.npmrc at line 2, The .npmrc setting omit-lockfile-registry-resolved is valid, but it can slow installs by forcing npm to re-fetch package manifests at install time. Review whether this config is still needed for the npm ci/cache: npm setup in this PR, and if CI install times regress, remove or reconsider it in .npmrc to preserve the expected speedup.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.npmrc:
- Line 2: The .npmrc setting omit-lockfile-registry-resolved is valid, but it
can slow installs by forcing npm to re-fetch package manifests at install time.
Review whether this config is still needed for the npm ci/cache: npm setup in
this PR, and if CI install times regress, remove or reconsider it in .npmrc to
preserve the expected speedup.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a0291d0d-79bc-432f-8d54-967e68fd8afd
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (8)
.github/actions/build/action.yml.github/actions/npm-publish/action.yml.github/workflows/cross-browser.yml.github/workflows/integration.yml.github/workflows/snyk.yml.github/workflows/test.yml.gitignore.npmrc
💤 Files with no reviewable changes (1)
- .gitignore
1476d3d to
7581d53
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/snyk.yml (1)
41-41: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueHardcoded Node version diverges from sibling workflow pattern.
test.ymldefinesNODE_VERSION: 22as a workflow-level env var and references it via${{ env.NODE_VERSION }}in its setup-node step. This file hardcodesnode-version: 22instead, risking drift if the Node version is bumped elsewhere but missed here.♻️ Suggested consistency fix
+env: + NODE_VERSION: 22 + jobs: check: ... steps: ... - name: Setup Node uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0 with: - node-version: 22 + node-version: ${{ env.NODE_VERSION }} cache: npm🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/snyk.yml at line 41, The setup-node step in the snyk workflow hardcodes the Node version instead of following the same pattern as the sibling workflow. Update the workflow to define a workflow-level NODE_VERSION env var and reference it in the node-version input for the setup-node action, matching the existing test workflow pattern so version bumps stay consistent across both workflows.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/snyk.yml:
- Line 41: The setup-node step in the snyk workflow hardcodes the Node version
instead of following the same pattern as the sibling workflow. Update the
workflow to define a workflow-level NODE_VERSION env var and reference it in the
node-version input for the setup-node action, matching the existing test
workflow pattern so version bumps stay consistent across both workflows.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 92e28746-0bc2-407b-b2a3-ade81913f995
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (8)
.github/actions/build/action.yml.github/actions/npm-publish/action.yml.github/workflows/cross-browser.yml.github/workflows/integration.yml.github/workflows/snyk.yml.github/workflows/test.yml.gitignore.npmrc
💤 Files with no reviewable changes (1)
- .gitignore
🚧 Files skipped from review as they are similar to previous changes (6)
- .github/actions/build/action.yml
- .github/workflows/test.yml
- .github/workflows/integration.yml
- .npmrc
- .github/workflows/cross-browser.yml
- .github/actions/npm-publish/action.yml
7581d53 to
2b6c3fd
Compare
2 participants
Summary
The lockfile was previously removed from version control because committing it exposed internal/private registry URLs in the `resolved` fields, leaking infrastructure details. It was added to `.gitignore` as a workaround.
We now restore it using `omit-lockfile-registry-resolved=true` in `.npmrc`, which strips those URLs from the lockfile so it can be safely committed without exposing registry configuration.
omit-lockfile-registry-resolved=trueto.npmrcso the lockfile can be committed without exposing internal registry URLspackage-lock.jsonfrom.gitignoreand restore it to version controlnpm cifor deterministic installscache: npmon allsetup-nodesteps for faster CI buildsactions/setup-nodeto a commit SHA in composite actions (build,npm-publish) to match the rest of the repo's pinning strategySummary by CodeRabbit
npm ci) across testing, cross-browser, integration, publishing, and security scanning.