chore: update config, deps, and project docs#394
Conversation
|
@Aspect022 is attempting to deploy a commit to the Drago's projects Team on Vercel. A member of the Team first needs to authorize it. |
github-actions
Bot
added
documentation
📝 WalkthroughWalkthroughReintroduces and standardizes Jest config entries and simplifies test discovery patterns; adds host allowlist validation and fallback logic for NEXT_PUBLIC_API_URL and sets TypeScript build errors to fail in Next.js config; adds Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
package.json (1)
161-161:⚠️ Potential issue | 🟠 Major
@types/jest ^30.0.0is mismatched with the Jest 29 runtime.
@types/jestv30.0.0 is a real package on npm. However, thejestruntime stays at^29.7.0,jest-environment-jsdomat^29.7.0, andts-jestat^29.4.6. The@types/jestpackage is a third-party library maintained at DefinitelyTyped and may not cover the latest Jest features or versions — and using it ahead of the runtime introduces the same risk in reverse: v30-typed APIs that don't exist in the v29 runtime will typecheck fine but panic at test-run time, while v29 APIs that changed signatures in v30 will emit TypeScript errors.The linked issue
#123clearly targets a full bump to Jest v30. Either:
- Complete the migration: bump
jest,jest-environment-jsdom, andts-jestto their v30 equivalents and follow the Jest v29→v30 migration guide, or- Revert
@types/jestto^29.7.0to match the current runtime until the full migration is done.🐛 Proposed fix (complete v30 migration)
- "@types/jest": "^30.0.0", + "@types/jest": "^30.0.0", // keep ... - "jest": "^29.7.0", + "jest": "^30.0.0", - "jest-environment-jsdom": "^29.7.0", + "jest-environment-jsdom": "^30.0.0", ... - "ts-jest": "^29.4.6", + "ts-jest": "^29.4.0", // ts-jest v29 is the last series; verify ts-jest v30 availabilityAlso applies to: 182-183, 191-191
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` at line 161, The `@types/jest` entry in package.json is pinned to ^30.0.0 while the runtime packages ("jest", "jest-environment-jsdom", "ts-jest") are v29, causing a types/runtime mismatch; either revert "@types/jest" to ^29.7.0 to match the existing runtime, or complete the upgrade by bumping "jest", "jest-environment-jsdom", and "ts-jest" to their v30 equivalents and follow the Jest v29→v30 migration guide; apply the chosen change consistently to all occurrences of "@types/jest" and the related test dependencies in package.json.
🧹 Nitpick comments (1)
jest.config.js (1)
31-31: Non-standard**tests**glob intestMatch.
**tests**is not a standard globstar — within a single path segment micromatch treats it as*tests*(matches any dir name containing "tests", including__tests__). It likely works, but it's non-idiomatic and will confuse maintainers expecting__tests__.♻️ Proposed clarification
- '<rootDir>/components/**/**tests**/**/*.test.{ts,tsx}', + '<rootDir>/components/**/__tests__/**/*.test.{ts,tsx}',🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@jest.config.js` at line 31, Replace the non‑standard glob segment "**tests**" in the testMatch entry with the idiomatic "__tests__" directory name: update the string '<rootDir>/components/**/**tests**/**/*.test.{ts,tsx}' to '<rootDir>/components/**/__tests__/**/*.test.{ts,tsx}' so the testMatch (the testMatch array entry) uses the conventional __tests__ pattern and avoids the confusing '**tests**' segment.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@next.config.js`:
- Line 161: The build config currently sets Next.js' TypeScript option
ignoreBuildErrors: true which suppresses all TS errors; revert this to the safe
default by removing that option or setting ignoreBuildErrors: false in
next.config.js (update the ignoreBuildErrors entry) so type errors fail the
build and surface in CI/deploy pipelines; if this was intended as a temporary
workaround, add a clear comment linking to an issue or migration task tracking
why it was introduced.
- Around line 127-129: The current guard uses envUrl.startsWith('http') to set
apiUrl from NEXT_PUBLIC_API_URL, which is too permissive; replace this with
validation against an explicit allowlist of allowed hostnames or origins: parse
envUrl, extract hostname (or origin), check it is in the allowlist (e.g.,
allowedHosts array) before assigning to apiUrl, and fallback to the default
'http://localhost:3001' if validation fails; update the logic around envUrl and
apiUrl to use this hostname/origin check instead of startsWith('http') and
ensure NEXT_PUBLIC_API_URL is only used when it passes the allowlist validation.
---
Outside diff comments:
In `@package.json`:
- Line 161: The `@types/jest` entry in package.json is pinned to ^30.0.0 while the
runtime packages ("jest", "jest-environment-jsdom", "ts-jest") are v29, causing
a types/runtime mismatch; either revert "@types/jest" to ^29.7.0 to match the
existing runtime, or complete the upgrade by bumping "jest",
"jest-environment-jsdom", and "ts-jest" to their v30 equivalents and follow the
Jest v29→v30 migration guide; apply the chosen change consistently to all
occurrences of "@types/jest" and the related test dependencies in package.json.
---
Nitpick comments:
In `@jest.config.js`:
- Line 31: Replace the non‑standard glob segment "**tests**" in the testMatch
entry with the idiomatic "__tests__" directory name: update the string
'<rootDir>/components/**/**tests**/**/*.test.{ts,tsx}' to
'<rootDir>/components/**/__tests__/**/*.test.{ts,tsx}' so the testMatch (the
testMatch array entry) uses the conventional __tests__ pattern and avoids the
confusing '**tests**' segment.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@Aspect022 update the branch, pull the recent changes then delete your lock file and run the command |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
package.json (2)
22-24:⚠️ Potential issue | 🟠 MajorNode engine floor is too low — root cause of both CI pipeline failures.
@farcaster/frame-sdk@0.1.12requiresnode >=22.11.0, butengines.nodeis set to">=20.0.0". This mismatch will triggerEBADENGINEwarnings in CI and cause resolution failures in environments with strict engine enforcement (e.g.,npm install --engine-strict).Either bump the lower bound to
>=22.11.0or downgrade/replace@farcaster/frame-sdkto a version that supports Node 20.🔧 Proposed fix (if bumping Node)
"engines": { - "node": ">=20.0.0", + "node": ">=22.11.0", "npm": ">=10.0.0" },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` around lines 22 - 24, The package.json "engines.node" lower bound is too low for the installed dependency `@farcaster/frame-sdk`@0.1.12, causing EBADENGINE CI failures; update package.json by changing the engines.node value from ">=20.0.0" to ">=22.11.0" (or alternatively replace/downgrade the `@farcaster/frame-sdk` dependency to a version compatible with Node 20) and ensure package-lock/npm lockfile is regenerated so CI uses the new engine constraint; look for "engines" and the dependency "@farcaster/frame-sdk" in package.json to make the change.
176-176:⚠️ Potential issue | 🟡 Minor
cross-envupstream repo archived — plan for future maintenance.
cross-env's GitHub repository was archived by its owner on November 19, 2025 and is now read-only. The latest published version is10.1.0(released September 29, 2025), which this project pins to, so there is no immediate breakage. However, no future security patches will be issued from upstream. Consider evaluating alternatives such as Node's built-in--env-fileflag (available since Node 20) or tracking if a community fork emerges.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` at line 176, The package currently pins the archived dependency "cross-env" at version "10.1.0"; replace it proactively by evaluating and switching to a maintained alternative or Node-native option: audit all uses of "cross-env" in package.json scripts, then either (A) if the runtime is Node 20+ convert scripts to use Node's built-in --env-file behavior and remove "cross-env" from devDependencies, or (B) choose a maintained substitute (e.g., dotenv-cli or env-cmd), update devDependencies and rewrite scripts to use that tool, and add a short changelog/issue note documenting the replacement plan and compatibility testing.
🧹 Nitpick comments (1)
package.json (1)
155-158:yarnandwebpack-bundle-analyzerare misplaced underdependencies.Both are build/development tools that have no role at runtime and should not be installed in production environments. They inflate the production dependency tree unnecessarily.
♻️ Suggested move to `devDependencies`
- "webpack-bundle-analyzer": "^5.2.0", "winston": "^3.19.0", "winston-daily-rotate-file": "^5.0.0", - "yarn": "^1.22.22", "zod": "^3.22.4" }, "devDependencies": { ... + "webpack-bundle-analyzer": "^5.2.0", + "yarn": "^1.22.22",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` around lines 155 - 158, package.json currently lists "yarn" and "webpack-bundle-analyzer" under dependencies; these are build/dev tools and should be moved to devDependencies. Remove "yarn" and "webpack-bundle-analyzer" from the dependencies block and add them to the devDependencies block (or run the equivalent package manager commands to install them with --save-dev), leaving runtime libs like "winston" and "winston-daily-rotate-file" in dependencies.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@package.json`:
- Around line 22-24: The package.json "engines.node" lower bound is too low for
the installed dependency `@farcaster/frame-sdk`@0.1.12, causing EBADENGINE CI
failures; update package.json by changing the engines.node value from ">=20.0.0"
to ">=22.11.0" (or alternatively replace/downgrade the `@farcaster/frame-sdk`
dependency to a version compatible with Node 20) and ensure package-lock/npm
lockfile is regenerated so CI uses the new engine constraint; look for "engines"
and the dependency "@farcaster/frame-sdk" in package.json to make the change.
- Line 176: The package currently pins the archived dependency "cross-env" at
version "10.1.0"; replace it proactively by evaluating and switching to a
maintained alternative or Node-native option: audit all uses of "cross-env" in
package.json scripts, then either (A) if the runtime is Node 20+ convert scripts
to use Node's built-in --env-file behavior and remove "cross-env" from
devDependencies, or (B) choose a maintained substitute (e.g., dotenv-cli or
env-cmd), update devDependencies and rewrite scripts to use that tool, and add a
short changelog/issue note documenting the replacement plan and compatibility
testing.
---
Nitpick comments:
In `@package.json`:
- Around line 155-158: package.json currently lists "yarn" and
"webpack-bundle-analyzer" under dependencies; these are build/dev tools and
should be moved to devDependencies. Remove "yarn" and "webpack-bundle-analyzer"
from the dependencies block and add them to the devDependencies block (or run
the equivalent package manager commands to install them with --save-dev),
leaving runtime libs like "winston" and "winston-daily-rotate-file" in
dependencies.
ℹ️ Review info
Configuration used: defaults
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)
jest.config.jsnext.config.jspackage.json
🚧 Files skipped from review as they are similar to previous changes (2)
- next.config.js
- jest.config.js
|
Not mergeable. |
2 participants
📝 Description
**Issue Reference Fixes #376 , Fixes #375
Summary of Changes (high-level)
package.json,jest.config.js,next.config.js,tailwind.config.js)@playwright/test,ts-jest,@testing-library/*)Why:
This PR establishes the foundational configuration and dependencies required for subsequent features and testing infrastructure (E2E tests, security hardening).
Impact: DevOps / Tooling, Documentation
Context / Motivation
This PR prepares the repository for end-to-end testing and improved security by ensuring all configuration files and dependencies are up-to-date and consistent. It isolates these changes to simplify the review of feature-specific PRs.
🏗️ Type of Change
Select the relevant categories:
⚙️ Technical Checklist
AI / Application Logic
GROQ_API_KEY.Web3 / Smart Contracts
smart_contractsand they passed.Frontend / UX / Accessibility
aria-*, alt text) and semantic HTML for new UI.Backend / Database
Security & Privacy
.envfiles are committed.Code Quality
npm run lint(or equivalent) and resolved reported issues.anyby default.🧪 Testing Evidence
Environment: local
Commands:
Results / Logs:
Manual UI Testing Steps:
N/A — No UI changes in this PR.
📸 Visual Proof (for UI / UX changes)
No UI changes in this PR.
👤 Contributor Status
🔁 Review & Impact
Breaking Changes
Dependencies
Added:
@playwright/test,ts-jestfor testing support.Backward Compatibility / Migrations
✅ Final Acknowledgements (Mandatory or will be marked invalid)
Summary by CodeRabbit
Release Notes
New Features
Improvements