-
-
Notifications
You must be signed in to change notification settings - Fork 600
refactor: Bump vite from 6.4.1 to 7.2.4 #2829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: alpha
Are you sure you want to change the base?
Conversation
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 6.4.1 to 7.2.4. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v7.2.4/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 7.2.4 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: mtrezza <5673677+mtrezza@users.noreply.github.com>
|
🚀 Thanks for opening this pull request! |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
📝 WalkthroughWalkthroughThe PR updates Node.js version requirements and dependencies. It removes support for Node 18 and 19, sets minimum versions to 20.19.0 and 22.12.0 across CI configuration and manifests, and upgrades Vite from 6.4.1 to 7.2.4. All version specifications are synchronized across configuration files. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (3)
.github/workflows/ci.yml(1 hunks).nvmrc(1 hunks)package.json(2 hunks)
🔇 Additional comments (2)
.nvmrc (1)
1-1: Node.js v20.19.0 is a legitimate release (March 13, 2025).The .nvmrc pinning to 20.19.0 is sound. This version includes require(esm) enabled by default and module syntax detection improvements.
package.json (1)
87-90: Verify vite-plugin-commonjs@0.10.4 compatibility with Vite 7.2.4 before merging.The config actively uses
vite-plugin-commonjsin the build pipeline. Web search found no explicit compatibility statement for this plugin with Vite 7, which is ESM-only. Whilevite-plugin-node-polyfills@0.24.0is confirmed compatible with Vite 7, the CommonJS plugin's behavior under Vite 7's ESM-only mode is unverified. Test the build thoroughly or confirm/upgrade to a Vite 7-compatible version.
| - name: Node 20 | ||
| NODE_VERSION: 20.15.1 | ||
| NODE_VERSION: 20.19.0 | ||
| - name: Node 22 | ||
| NODE_VERSION: 22.4.1 | ||
| NODE_VERSION: 22.12.0 | ||
| fail-fast: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Show the relevant file with line numbers for verification
if [ -f ".github/workflows/ci.yml" ]; then
sed -n '1,240p' .github/workflows/ci.yml | nl -ba | sed -n '1,240p'
else
echo ".github/workflows/ci.yml not found"
fiRepository: parse-community/Parse-SDK-JS
Length of output: 112
🏁 Script executed:
#!/bin/bash
if [ -f ".github/workflows/ci.yml" ]; then
cat -n .github/workflows/ci.yml | sed -n '1,240p'
else
echo ".github/workflows/ci.yml not found"
fiRepository: parse-community/Parse-SDK-JS
Length of output: 3664
🌐 Web query:
actions/setup-node v3 Node 22 support caching differences
💡 Result:
Short answer — yes. actions/setup-node v3 supports Node 22 (you can pass node-version: 22) and includes built‑in dependency caching, but the cache behavior differs from a full node_modules cache:
Key points
- Node 22: v3 accepts semver like "22" / "22.x" / specific 22.x.y; it resolves versions via the action's node-versions source and falls back to node dist if needed. [1]
- Built‑in package-manager caching: setup-node v3 can automatically cache package manager caches for npm, yarn and pnpm (pnpm support requires >= 6.10). Caching is opt‑in via the cache input (e.g. cache: 'npm'|'yarn'|'pnpm'). [2][3]
- What is cached: the action caches the package manager’s global cache (tarballs, registry cache), not node_modules or the full install tree. This lets caches be reused across Node versions but does not restore node_modules itself. [2][4]
- Cache key behavior: by default the action looks for the repo lockfile (package-lock.json / yarn.lock / pnpm-lock.yaml) in the repo root and includes its hash in the cache key; use cache-dependency-path to point to multiple or nested lockfiles or globs. [2][4]
- PNPM notes: pnpm caching requires pnpm >= 6.10 and setup-node may rely on pnpm/action-setup for installing a specific pnpm version before using cache. [4]
Sources
[1] actions/setup-node README (supported version syntax, node-version behavior).
[2] actions/setup-node docs — Advanced usage (cache, cache-dependency-path, npm/yarn/pnpm details).
[3] setup-node releases (recent changes around caching behavior).
Align actions major versions in the build job (lines 88–94).
build uses actions/checkout@v3 + actions/setup-node@v3 while most other jobs use @v4; setup-node@v3 supports Node 22 and npm caching, but mixing major versions may cause inconsistent behavior (caching/feature differences). Update the build job to use v4 for consistency:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
- name: Use Node.js
- uses: actions/setup-node@v3
+ uses: actions/setup-node@v4
with:
node-version: ${{ matrix.NODE_VERSION }}
cache: npmCommittable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
.github/workflows/ci.yml around lines 80 to 84: the build job mixes actions
major versions (uses actions/checkout@v3 and actions/setup-node@v3) while other
jobs target @v4; update the build job to use actions/checkout@v4 and
actions/setup-node@v4 so the major versions are consistent across jobs, keeping
the same NODE_VERSION entries and existing caching configuration.
| "engines": { | ||
| "node": "18 || 19 || 20 || 22" | ||
| "node": ">=20.19.0 || >=22.12.0" | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
# Search for CI configuration files that might reveal intended Node versions
find . -type f \( -name ".github" -o -name "*.yml" -o -name "*.yaml" \) | head -20Repository: parse-community/Parse-SDK-JS
Length of output: 293
🏁 Script executed:
# Look for any workflow files or CI configuration
find . -path "*/.github/workflows/*" -type fRepository: parse-community/Parse-SDK-JS
Length of output: 232
🏁 Script executed:
# Check for .npmrc, .node-version, or .nvmrc files
find . -type f \( -name ".npmrc" -o -name ".node-version" -o -name ".nvmrc" -o -name ".tool-versions" \)Repository: parse-community/Parse-SDK-JS
Length of output: 80
🌐 Web query:
npm semver range OR operator behavior "||" engines.node version matching
💡 Result:
Short answer: In npm semver ranges the "||" operator is a logical OR between comparator sets — each side is a comparator set (an intersection of comparators), and a version satisfies the whole range if it satisfies every comparator in at least one of those sets. npm uses the node-semver rules to evaluate engines.node, and the engines field is checked (advisory by default; strict enforcement requires config/behavior that has changed across npm versions). [1][2]
Details (one-line each):
- "A range is composed of one or more comparator sets, joined by
||. A version matches a range iff every comparator in at least one of the||-separated comparator sets is satisfied." — node-semver. [1] - npm evaluates package.json engines.node using semver semantics (so
">=14 <15 || >=16"means any version matching either comparator set). The engines field is advisory unless the user/installer enforces engine-strict behavior (behavior changed across npm versions). [2]
Sources:
[1] node-semver README (npm's semver implementation) — range and || semantics.
[2] npm docs — package.json engines field behavior.
🌐 Web query:
npm engines.node ">=20.19.0 || >=22.12.0" how does OR work in semantic versioning
💡 Result:
Short answer: The || operator joins alternative comparator sets — a version satisfies the range if it satisfies any side. So ">=20.19.0 || >=22.12.0" means "any Node version >=20.19.0 OR any Node version >=22.12.0" (i.e. satisfy either comparator). In practice those two comparators overlap, so the whole range is equivalent to just ">=20.19.0". (github.com)
Note: people often write "^20.19.0 || >=22.12.0" to mean "Node 20.x (from 20.19.0) OR Node >=22.12.0" — that is different because ^20.19.0 limits to 20.x while ">=20.19.0" does not. Example discussion in Mocha issue. (github.com)
Citations:
- 1: https://github.com/npm/node-semver?utm_source=openai
- 2: 🧹 Versioning: Bump minimum Node.js version from 18.18.0 to 20.19.0 mochajs/mocha#5358
🏁 Script executed:
cat .nvmrcRepository: parse-community/Parse-SDK-JS
Length of output: 79
🏁 Script executed:
cat ./.github/workflows/ci.yml | head -100Repository: parse-community/Parse-SDK-JS
Length of output: 2535
🏁 Script executed:
# Check if there are any other references to Node version requirements in documentation
grep -r "node.*\(20\|21\|22\)" --include="*.md" --include="*.json" --include="*.yml" | grep -v node_modules | head -20Repository: parse-community/Parse-SDK-JS
Length of output: 1526
engines.node range doesn't enforce the intended minimum for Node 22.
The CI workflow explicitly tests only Node 20.19.0 and Node 22.12.0, confirming the intent to exclude Node 21 and early Node 22 versions. However, >=20.19.0 || >=22.12.0 is equivalent to just >=20.19.0 due to the overlapping ranges, meaning Node 22.0–22.11 would still be allowed and aren't rejected by the range.
Use:
"engines": {
- "node": ">=20.19.0 || >=22.12.0"
+ "node": ">=20.19.0 <21 || >=22.12.0"
}This properly enforces the tested versions and aligns with the CI matrix.
🤖 Prompt for AI Agents
In package.json around lines 121 to 123, the engines.node range ">=20.19.0 ||
>=22.12.0" is effectively just ">=20.19.0" and allows untested Node 22.0–22.11;
change the range to explicitly allow Node 20 from 20.19.0 up to (but not
including) 21 and Node 22 from 22.12.0 onward (for example: >=20.19.0 <21 ||
>=22.12.0) so the package enforces the CI-tested minimums and excludes
intermediate/untested versions.
Pull Request
Issue
Closes: #2794
Approach
See #2802
Vite 7.x requires Node.js 20.19+ or 22.12+. The CI was failing because it tested against older Node versions.
Changes:
.github/workflows/ci.yml: Updated Node matrix to 20.19.0 and 22.12.0, removed Node 18 (no longer supported by vite 7).nvmrc: 20.15.0 → 20.19.0package.jsonengines:"18 || 19 || 20 || 22"→">=20.19.0 || >=22.12.0"Tasks
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.