build(deps): consolidate dependabot bumps from PRs #2, #4, #5, #7, #15#17
build(deps): consolidate dependabot bumps from PRs #2, #4, #5, #7, #15#17adm01-debug wants to merge 9 commits into
Conversation
X-Lovable-Edit-ID: edt-f714f04f-9c25-454e-9ea4-f5de2ac34f9a Co-authored-by: adm01-debug <231131902+adm01-debug@users.noreply.github.com>
Bumps the development-minor group with 1 update: [postcss](https://github.com/postcss/postcss). Updates `postcss` from 8.5.10 to 8.5.12 - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](postcss/postcss@8.5.10...8.5.12) --- updated-dependencies: - dependency-name: postcss dependency-version: 8.5.12 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…ent-minor-5f44a83626' into claude/resolve-pr-conflicts-KWeDG
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughConfiguration and dependency updates to the project. The Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
date-fns@^4 (PR #4) conflicts with react-day-picker@8.10's peer dep (date-fns@^2 || ^3). Adds repo-wide legacy-peer-deps so 'npm ci' succeeds without forcing a major bump of react-day-picker (which has breaking API changes in v9).
c0b6754 to
9c59771
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.npmrc:
- Line 1: Remove the global legacy-peer-deps=true entry from .npmrc and instead
either (A) upgrade the react-day-picker dependency in package.json to v9
(replace "react-day-picker": "8.x" with "9.x") and delete the .npmrc change, or
(B) if upgrading is out of scope, remove .npmrc and add a targeted package.json
overrides entry under the "overrides" key that pins the peer resolution between
react-day-picker and date-fns (keep the rest of peer checks strict); update
package.json accordingly and run a fresh install to verify the peer conflict is
resolved.
In `@package.json`:
- Line 86: The project is using date-fns@^4.1.0 which is incompatible with the
pinned react-day-picker@^8.10 peer range; either upgrade react-day-picker to
^9.x (preferred) or pin date-fns to ^3.x to avoid runtime breakage—update
package.json to change the react-day-picker version to ^9.x (or change date-fns
to ^3.x if upgrading the picker is out of scope) and run install; after
changing, run the test suite and manually verify all date-fns usages (notably in
src/lib/date-utils.ts and any files importing format, formatDistance, parseISO,
and ptBR) to ensure imports and locale paths match the chosen date-fns major
version.
- Line 81: Move "vitest" and "@vitest/coverage-v8" from dependencies to
devDependencies in package.json, then re-run the full test suite on the current
main branch (pre-bump) to capture a baseline; specifically confirm whether the 2
failing / 3562 tests are present before upgrading. After moving, keep Vitest
pinned to v3 (or roll back the bump) until you address breaking changes in v4:
search tests that use vi.restoreAllMocks() (e.g., tests/utils/viacep.test.ts and
tests/hooks/useAIRecommendations.test.ts) and either replace vi.fn() mocks with
vi.spyOn() where appropriate or explicitly reset created vi.fn() mocks in
afterEach to maintain isolation. Finally, check compatibility between the vite
version (vite: ^5.4.19) and the intended Vitest version and update
vitest.config.ts according to the Vitest v4 migration guide if you proceed with
the major upgrade.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e71538b7-8e90-4596-bab3-df0aacbe8ca4
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
.npmrcpackage.json
| @@ -0,0 +1 @@ | |||
| legacy-peer-deps=true | |||
There was a problem hiding this comment.
Project-wide legacy-peer-deps=true is too broad — prefer a targeted fix.
Per the PR description this flag exists solely to paper over the react-day-picker@8.10 ↔ date-fns@4 peer mismatch, but enabling it globally also silences every other current and future peer conflict for this repo and for anyone using npm ci in CI. Two safer alternatives:
- Upgrade
react-day-pickerto v9 (which officially supportsdate-fns@4) and drop.npmrcentirely — this is the recommended fix and removes the root cause. - If the v9 upgrade is out of scope here, scope the override narrowly via
package.jsonoverridesinstead of a global install flag, e.g.:
♻️ Targeted override (keeps strict peer checks elsewhere)
+ "overrides": {
+ "react-day-picker": {
+ "date-fns": "$date-fns"
+ }
+ },…and remove .npmrc.
react-day-picker v9 date-fns v4 peer dependency support
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.npmrc at line 1, Remove the global legacy-peer-deps=true entry from .npmrc
and instead either (A) upgrade the react-day-picker dependency in package.json
to v9 (replace "react-day-picker": "8.x" with "9.x") and delete the .npmrc
change, or (B) if upgrading is out of scope, remove .npmrc and add a targeted
package.json overrides entry under the "overrides" key that pins the peer
resolution between react-day-picker and date-fns (keep the rest of peer checks
strict); update package.json accordingly and run a fresh install to verify the
peer conflict is resolved.
| "@typescript-eslint/eslint-plugin": "^8.18.0", | ||
| "@typescript-eslint/parser": "^8.18.0", | ||
| "@vitest/coverage-v8": "^3.2.4", | ||
| "@vitest/coverage-v8": "^4.1.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Surface vitest API surfaces touched by v4 breaking changes.
set -e
echo "=== Third-arg test()/describe() options (removed in v4) ==="
ast-grep --pattern 'test($_, $_, $_)'
ast-grep --pattern 'describe($_, $_, $_)'
echo "=== restoreAllMocks / spyOn usage ==="
rg -nP "vi\.(restoreAllMocks|resetAllMocks|spyOn|fn)\b" -C1
echo "=== automocked getters / vi.mock factories that may rely on original getters ==="
rg -nP "vi\.mock\(" -C2
echo "=== basic reporter usage ==="
rg -nP "['\"]basic['\"]" --type=ts --type=js -C1Repository: adm01-debug/Promo_Gifts
Length of output: 127
🏁 Script executed:
#!/bin/bash
# Get the full output of the pattern search, handling errors gracefully
echo "=== Third-arg test()/describe() options (removed in v4) ==="
ast-grep --pattern 'test($_, $_, $_)' 2>&1 || echo "(no matches or error)"
ast-grep --pattern 'describe($_, $_, $_)' 2>&1 || echo "(no matches or error)"
echo ""
echo "=== restoreAllMocks / spyOn usage ==="
rg -nP "vi\.(restoreAllMocks|resetAllMocks|spyOn|fn)\b" -C1 2>&1 || echo "(no matches)"
echo ""
echo "=== automocked getters / vi.mock factories ==="
rg -nP "vi\.mock\(" -C2 2>&1 || echo "(no matches)"
echo ""
echo "=== basic reporter usage ==="
rg -nP "['\"]basic['\"]" --type=ts --type=js -C1 2>&1 || echo "(no matches)"Repository: adm01-debug/Promo_Gifts
Length of output: 50380
🏁 Script executed:
#!/bin/bash
# Check package.json and vitest configuration
echo "=== package.json lines around 81 and 127 ==="
sed -n '75,95p' package.json
echo ""
sed -n '120,135p' package.json
echo ""
echo "=== vitest.config.ts content ==="
cat vitest.config.ts 2>&1 || echo "(file not found)"
echo ""
echo "=== Vite version pin in package.json ==="
rg -n '"vite"' package.json | head -5Repository: adm01-debug/Promo_Gifts
Length of output: 2496
🏁 Script executed:
#!/bin/bash
# Check where vitest packages are located in package.json
echo "=== Full dependencies section ==="
rg -A 500 '"dependencies"' package.json | head -50
echo ""
echo "=== Full devDependencies section ==="
rg -A 200 '"devDependencies"' package.json | head -60Repository: adm01-debug/Promo_Gifts
Length of output: 2487
Move vitest and @vitest/coverage-v8 to devDependencies (lines 81, 127) — these are build/test tools and will be installed in production otherwise.
Vitest 3 → 4 is a major version with breaking changes that affect this codebase. Most critical: vi.restoreAllMocks() in your beforeEach blocks (found in tests/utils/viacep.test.ts, tests/hooks/useAIRecommendations.test.ts, and others) no longer clears mocks created with vi.fn() in v4 — only those from vi.spyOn(). Since the test suite uses vi.fn() extensively, test isolation may break silently. Re-run the test suite on main (pre-bump) to establish a baseline, then confirm 2 failures / 3562 tests aren't a regression from v4's mock behavior changes.
Also verify that vite: ^5.4.19 (line 141) won't conflict with Vitest 4, which may pull in Vite 6 or 7. Review vitest.config.ts against the v4 migration guide to ensure your current settings are compatible.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 81, Move "vitest" and "@vitest/coverage-v8" from
dependencies to devDependencies in package.json, then re-run the full test suite
on the current main branch (pre-bump) to capture a baseline; specifically
confirm whether the 2 failing / 3562 tests are present before upgrading. After
moving, keep Vitest pinned to v3 (or roll back the bump) until you address
breaking changes in v4: search tests that use vi.restoreAllMocks() (e.g.,
tests/utils/viacep.test.ts and tests/hooks/useAIRecommendations.test.ts) and
either replace vi.fn() mocks with vi.spyOn() where appropriate or explicitly
reset created vi.fn() mocks in afterEach to maintain isolation. Finally, check
compatibility between the vite version (vite: ^5.4.19) and the intended Vitest
version and update vitest.config.ts according to the Vitest v4 migration guide
if you proceed with the major upgrade.
| "clsx": "^2.1.0", | ||
| "cmdk": "^0.2.0", | ||
| "date-fns": "^2.30.0", | ||
| "date-fns": "^4.1.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm peer requirement of the currently pinned react-day-picker major
# and find every date-fns usage site that needs re-validation under v4.
set -e
echo "=== react-day-picker peer deps (v8 latest vs v9 latest) ==="
curl -s https://registry.npmjs.org/react-day-picker | jq '.versions | to_entries | map(select(.key | test("^8\\.")))[-1].value | {version: .version, peerDependencies}'
curl -s https://registry.npmjs.org/react-day-picker | jq '.versions | to_entries | map(select(.key | test("^9\\.")))[-1].value | {version: .version, peerDependencies}'
echo "=== date-fns import sites in repo ==="
rg -nP --type=ts --type=tsx "from\s+['\"]date-fns(/[^'\"]+)?['\"]" -C1Repository: adm01-debug/Promo_Gifts
Length of output: 427
🏁 Script executed:
#!/bin/bash
# Find date-fns import sites in repo (fix the tsx type issue)
echo "=== Finding date-fns imports ==="
rg -nP --type ts "from\s+['\"]date-fns" -C1 || true
echo ""
echo "=== Current package.json dependencies ==="
head -120 package.json | tail -40
echo ""
echo "=== Checking .npmrc for legacy-peer-deps ==="
cat .npmrc 2>/dev/null || echo "(no .npmrc found)"Repository: adm01-debug/Promo_Gifts
Length of output: 31431
🏁 Script executed:
#!/bin/bash
# Verify react-day-picker@9 support for date-fns@4
echo "=== Checking react-day-picker@9 npm registry details ==="
curl -s https://registry.npmjs.org/react-day-picker/9.14.0 | jq '{peerDependencies, optionalDependencies, description}' 2>/dev/null || echo "Failed to fetch"
echo ""
echo "=== Checking if date-fns v4 has breaking changes from v3 ==="
echo "Looking for: locale module restructuring, ESM-only, removed default exports"Repository: adm01-debug/Promo_Gifts
Length of output: 405
date-fns v4 jump incompatible with pinned react-day-picker@^8.10 — upgrade picker or pin date-fns to ^3.x.
react-day-picker@8.10 declares date-fns peer as ^2.28 || ^3.0; v4 is outside this range. The .npmrc setting legacy-peer-deps=true suppresses the peer violation but does not make the runtime safe. v8 was authored against v2 types/behaviors; date-fns v3 and v4 introduced real breaking changes (ESM-only, removed default exports, locale module restructuring).
Recommended fix: Upgrade react-day-picker to ^9.x in this PR — v9 removes the date-fns peer constraint entirely and explicitly supports v4. If out of scope, hold date-fns at ^3.x pending picker upgrade.
Verify all date-fns code paths under v4: The codebase has 40+ files importing date-fns, including src/lib/date-utils.ts and widespread use of format, formatDistance, parseISO, and ptBR locale imports. These specific APIs were affected in v3→v4 transitions (locale subpaths, timezone handling, etc.) and require runtime validation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 86, The project is using date-fns@^4.1.0 which is
incompatible with the pinned react-day-picker@^8.10 peer range; either upgrade
react-day-picker to ^9.x (preferred) or pin date-fns to ^3.x to avoid runtime
breakage—update package.json to change the react-day-picker version to ^9.x (or
change date-fns to ^3.x if upgrading the picker is out of scope) and run
install; after changing, run the test suite and manually verify all date-fns
usages (notably in src/lib/date-utils.ts and any files importing format,
formatDistance, parseISO, and ptBR) to ensure imports and locale paths match the
chosen date-fns major version.
There was a problem hiding this comment.
Pull request overview
Consolidates multiple Dependabot dependency upgrades into a single PR, resolving conflicts and updating the npm lockfile and install configuration to keep CI installs working.
Changes:
- Bump key dependencies/dev tooling (including
vitest,@vitest/coverage-v8,date-fns,framer-motion,react-helmet-async,postcss). - Regenerate
package-lock.jsonto reflect the updated dependency graph. - Add
.npmrcconfiguration to bypass peer dependency conflicts during install.
Reviewed changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| package.json | Updates several dependency version ranges, including a major vitest upgrade. |
| package-lock.json | Updates resolved versions/transitives for the dependency bumps (including vitest@4.x’s dependency graph). |
| .npmrc | Adds legacy-peer-deps=true to allow installs despite peer dependency mismatches. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "tailwind-merge": "^2.2.0", | ||
| "vaul": "^0.9.0", | ||
| "vitest": "^3.2.4", | ||
| "vitest": "^4.1.0", |
There was a problem hiding this comment.
Bumping to vitest v4 raises the minimum supported Node version (lockfile shows vitest requires Node ^20) and also requires Vite ^6+. This repo still pins Vite to ^5.4.19, so npm will install a separate Vite version under vitest, which can lead to divergent behavior between dev/build and tests. Consider either upgrading Vite to a compatible major (>=6) or keeping vitest on v3 until the Vite upgrade is done; also consider adding a package.json "engines" entry / updating docs to reflect the Node >=20 requirement.
| "vitest": "^4.1.0", | |
| "vitest": "^3.2.4", |
| @@ -0,0 +1 @@ | |||
| legacy-peer-deps=true | |||
There was a problem hiding this comment.
Setting legacy-peer-deps=true globally makes npm ignore peer dependency conflicts across the whole project, which can mask unrelated dependency issues and allow incompatible combinations to slip in later. If the intent is only to work around the react-day-picker/date-fns peer range, consider a more targeted approach (e.g., upgrading the peer-conflicting package) or at least documenting this constraint prominently so contributors understand why peer deps are being bypassed.
| legacy-peer-deps=true |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9c5977106c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "clsx": "^2.1.0", | ||
| "cmdk": "^0.2.0", | ||
| "date-fns": "^2.30.0", | ||
| "date-fns": "^4.1.0", |
There was a problem hiding this comment.
Revert date-fns v4 until react-day-picker is upgraded
This bump puts the app on an unsupported runtime combination: date-fns is now ^4.1.0, while react-day-picker remains ^8.10.0 and its peer range in the lockfile is still date-fns: ^2.28.0 || ^3.0.0 (package-lock.json around line 11964). Because .npmrc now enables legacy-peer-deps, installs no longer fail fast on this mismatch, so calendar behavior can regress in production without an install-time signal.
Useful? React with 👍 / 👎.
| "tailwind-merge": "^2.2.0", | ||
| "vaul": "^0.9.0", | ||
| "vitest": "^3.2.4", | ||
| "vitest": "^4.1.0", |
There was a problem hiding this comment.
Upgrade Vite when adopting Vitest 4
Upgrading vitest to ^4.1.0 without also upgrading root vite leaves the toolchain misaligned (vite is still ^5.4.19). In the generated lockfile, Vitest 4 requires vite: ^6 || ^7 || ^8 and npm resolves a separate nested vite@8 under node_modules/vitest, so tests run against a different Vite major than the app build, which is a common source of plugin/config breakage.
Useful? React with 👍 / 👎.
Closing — base
mainhas moved (force-pushed to lovable-sync HEADf3e6de1cto consolidate the divergent development line). The 5 dependency bumps consolidated here will be re-applied in a fresh PR against new main.Root-cause analysis (kept here for posterity):
The
mainbranch diverged from the active development line on 2026-04-23 12:14 UTC when the Lovable bot pushed 4 commits to main and then switched to creating side branches (lovable-sync-*), abandoning main. Net result: 9 stalelovable-sync-*PRs + 1 orphan PR (#11) + active development happening nowhere visible. Resolution: force-pushed main to the latestlovable-syncHEAD, closed all stale PRs.