Repository navigation
chore: update package versions and configurations for improved compatibility and performance; includes dependency upgrades and adjustments to TypeScript configurations - #53
Conversation
…ibility and performance; includes dependency upgrades and adjustments to TypeScript configurations
📝 WalkthroughWalkthroughThis PR performs comprehensive dependency and configuration upgrades across the entire monorepo. It updates SWC toolchain versions in Cargo.toml, bumps development and runtime dependencies in package.json files, standardizes TypeScript module resolution by removing baseUrl settings, refactors Vitest configurations, and updates example applications to use newer HeroUI patterns. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
examples/example-rspack/package.json (1)
58-73:⚠️ Potential issue | 🟡 MinorAlign Browserslist with Tailwind CSS v4 minimum browser requirements.
Tailwind CSS v4 requires modern browsers (Chrome 111+, Safari 16.4+, Firefox 128+) for its core CSS features. The current
">0.2%, not dead"browserslist targets much older browsers, creating a mismatch. Either narrow the production browserslist to match Tailwind v4 support or stay on Tailwind v3.Reference: https://tailwindcss.com/docs/browser-support/
🔧 Example alignment
"browserslist": { "production": [ - ">0.2%", - "not dead", - "not op_mini all" + "Chrome >= 111", + "Edge >= 111", + "Firefox >= 128", + "Safari >= 16.4", + "iOS >= 16.4" ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@examples/example-rspack/package.json` around lines 58 - 73, The production browserslist in package.json is too broad for Tailwind CSS v4; update the "browserslist" production target to only include modern browsers that meet Tailwind v4 minimum requirements (e.g., Chrome 111+, Safari 16.4+, Firefox 128+) or else revert to Tailwind v3; locate the "browserslist" object in package.json and replace the production array (currently ">0.2%, not dead, not op_mini all") with a narrowed set of targets that reflect Chrome >=111, Safari >=16.4, and Firefox >=128, ensuring build tools and PostCSS use the new targets.
🧹 Nitpick comments (7)
packages/inspector-babel-plugin/vitest.config.ts (1)
4-7:resolve.tsconfigPaths: trueis a valid Vitest/Vite option, but consider using thevite-tsconfig-pathsplugin for monorepo consistency.As of Vite 8+,
resolve.tsconfigPaths: trueis a supported native option that honors tsconfigpathsaliases. Vitest inherits this from Vite, so the current configuration inpackages/inspector-babel-plugin/vitest.config.ts,packages/inspector-component/vitest.config.ts, andcrates/inspector-swc-plugin/vitest.config.tsis technically valid.However, for monorepo setups with multiple path aliases (like
@hyperse/inspector-common), official Vite/Vitest documentation still recommends thevite-tsconfig-pathsplugin as it provides more advanced features (projects, loose matching, etc.) and better handles edge cases. While native support works for basic scenarios, the plugin ensures greater reliability and consistency across complex monorepos.Consider adding the plugin for clarity and reliability:
Suggested change
+import tsconfigPaths from 'vite-tsconfig-paths'; import { configDefaults, defineConfig } from 'vitest/config'; export default defineConfig({ - plugins: [], - resolve: { - tsconfigPaths: true, - }, + plugins: [tsconfigPaths()],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/inspector-babel-plugin/vitest.config.ts` around lines 4 - 7, Replace the native resolve.tsconfigPaths usage with the official vite-tsconfig-paths plugin: import viteTsconfigPaths from 'vite-tsconfig-paths' and add viteTsconfigPaths() to the plugins array in vitest.config.ts, and remove or disable resolve: { tsconfigPaths: true } (apply the same change to the other vitest.config.ts files mentioned) so tsconfig path aliases are resolved via the plugin for monorepo consistency.crates/inspector-swc-plugin/package.json (1)
48-49: Align SWC package version ranges to prevent future drift.
@swc/coreuses~1.15.30while@swc/wasm-webuses^1.15.30. Although both currently resolve to 1.15.30, the different ranges allow them to diverge on future releases—~locks patch-only updates while^permits minor version updates. Use~1.15.30for both to keep them synchronized.♻️ Proposed fix
"@hyperse/inspector-common": "workspace:*", "@swc/core": "~1.15.30", - "@swc/wasm-web": "^1.15.30", + "@swc/wasm-web": "~1.15.30",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/inspector-swc-plugin/package.json` around lines 48 - 49, The two SWC dependency ranges are inconsistent—@swc/core is "~1.15.30" while `@swc/wasm-web` is "^1.15.30"; change the `@swc/wasm-web` entry to "~1.15.30" so both `@swc/core` and `@swc/wasm-web` use the same patch-locked range, and update lockfile/install (npm/yarn) afterward to ensure the resolved versions remain aligned.packages/inspector-common/package.json (1)
48-48: Keep Node typings aligned with the supported runtime.Line 48 typechecks against Node 25 declarations while Line 60 still supports Node
>=18.0.0. This can mask accidental usage of newer Node APIs that fail for supported Node 18 users.Also applies to: 59-60
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/inspector-common/package.json` at line 48, The `@types/node` devDependency currently pins Node typings to ^25.6.0 which is inconsistent with the package's supported runtime (Node >=18.0.0); update the "@types/node" entry in package.json to a types version that matches Node 18 (for example ^18.x or a specific 18.y.z like ^18.16.0) so typechecks reflect the supported runtime and avoid accidental usage of newer Node APIs; ensure the change is applied where "@types/node" appears (lines referencing that dependency) and run the typecheck to verify no new type errors.packages/inspector-component/package.json (2)
69-72: Avoid making a React patch bump a consumer constraint unless required.Lines 70-71 now reject or warn for consumers on React
19.2.3/19.2.4. If no public API or critical bugfix specifically requires19.2.5, keep the peer range broader and use19.2.5only for local dev/test dependencies.Possible peer range adjustment
- "react": ">=19.2.5", - "react-dom": ">=19.2.5" + "react": ">=19.2.0", + "react-dom": ">=19.2.0"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/inspector-component/package.json` around lines 69 - 72, The peerDependencies currently pin "react" and "react-dom" to ">=19.2.5" which unnecessarily rejects 19.2.3/19.2.4 consumers; update the "peerDependencies" entries for the keys "react" and "react-dom" to a broader range (for example ">=19.2.3" or a caret range like "^19.2.3" or ">=19.2.3 <20") so consumers on 19.2.3/19.2.4 are allowed, and keep any requirement for 19.2.5 limited to devDependencies/test setup only.
50-50: Keep Node typings aligned with the supported runtime.Line 50 typechecks against Node 25 declarations while Line 79 still supports Node
>=18.0.0. That weakens the package’s Node 18 compatibility guarantee.Also applies to: 78-79
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/inspector-component/package.json` at line 50, The package.json currently depends on "@types/node" at a Node 25 typings level which is inconsistent with the package's supported runtime (Node >=18.0.0); update the "@types/node" entry to a version that targets Node 18 (for example to a caret range like ^18.x or a specific 18.x.y release) so the typings match the engine target, and ensure any other occurrences/entries referencing Node versions (e.g., the "engines" field) remain consistent; after changing the "@types/node" version, run the typechecker to verify no new type errors are introduced.packages/inspector/package.json (1)
48-48: Keep Node typings aligned with the supported runtime.Line 48 typechecks against Node 25 declarations, but Line 77 still advertises Node
>=18.0.0. That can let Node 20/25-only APIs compile and then fail for Node 18 consumers. Either pin@types/nodeto the lowest supported runtime or raiseengines.nodeand CI accordingly.Also applies to: 76-77
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/inspector/package.json` at line 48, package.json currently depends on "@types/node": "^25.6.0" while "engines.node" still advertises ">=18.0.0", which allows Node 25-only types to slip through; either pin "@types/node" to the lowest supported runtime (e.g., change "@types/node" to a version matching Node 18) OR raise "engines.node" to the minimum Node version that matches the types (and update CI matrix accordingly); update the package.json "dependencies/devDependencies" entry for "@types/node" and/or the "engines.node" field and adjust CI job node versions so types and runtime are aligned.website/package.json (1)
49-52: Add Node.js 20 engine constraint for consistency.The website now depends on Docusaurus 3.10.0, which requires Node.js 20.0+. While the GitHub Pages deployment workflow is already pinned to Node 20.x, adding an
enginesfield towebsite/package.jsonhelps developers understand the local development requirement and provides clear guidance.Suggested package metadata update
- "packageManager": "yarn@4.3.0" + "packageManager": "yarn@4.3.0", + "engines": { + "node": ">=20.0.0" + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@website/package.json` around lines 49 - 52, Add an engines constraint to package.json to require Node 20 for local development: insert an "engines" object at the package.json root (near existing deps like "@docusaurus/core") with e.g. "node": ">=20.0.0 <21.0.0" so the project explicitly documents and enforces the Node.js 20 requirement.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Cargo.toml`:
- Around line 25-45: The Cargo.toml pins swc_core = "64.0.0" which is
incompatible with the swc versions bundled by the targeted Next.js (≈56.x) and
Rspack (≈62.x) releases; to fix, change the swc_core dependency (and any tightly
coupled swc_* entries that require exact swc_core compatibility such as
swc_ecma_utils, swc_core, swc, swc_parallel) to a version that matches the
bundled runtime (e.g., align to 62.x for Rspack 2.0.0 or to the specific
`@next/swc` version for Next.js 16.2.4) OR explicitly document and bump the
README/examples to require the newer toolchain if you intentionally want 64.0.0;
update the swc_core declaration and any sibling swc_* pins in Cargo.toml (and
adjust README/example version constraints) so runtime WASM plugin ABI matches
the shipped swc.
In `@crates/inspector-swc-plugin/package.json`:
- Around line 55-57: The package advertises Node ">=18.0.0" but depends on
vitest@^4.1.5 which requires Node 20+, so update the engines field in
package.json to require Node >=20.0.0; open the package.json entry for "engines"
and change the Node version constraint (reference: the vitest dependency and the
"engines" field) so the declared Node range matches Vitest's requirements and
avoids install/runtime failures on Node 18/19.
In `@examples/example-nextjs/package.json`:
- Around line 16-20: The package.json scripts block removed the "lint" entry
while adding eslint and `@hyperse/eslint-config-hyperse` as devDependencies;
restore a lint script in the scripts object (e.g., add a "lint" script that runs
eslint across the project files such as "eslint . --ext .js,.jsx,.ts,.tsx" or
similar) so the new devDependencies are actually usable, and ensure the
project's ESLint config references `@hyperse/eslint-config-hyperse`; alternatively
remove those two devDependencies if you prefer not to provide a lint task.
- Line 58: Add a Node engine constraint and make the TypeScript config
v6-compatible: update package.json to include an "engines" entry with "node":
">=20.19.0" so ESLint 10.2.1's Node requirement is satisfied; update
tsconfig.json to set "types": ["node", "vitest/globals"] (or include "node"
alongside existing "vitest/globals") and consider adding an explicit "rootDir"
if your build expects one; finally, review the ESLint config dependency set (the
shared config `@hyperse/eslint-config-hyperse` and any eslint-plugin-react-*
transitive deps) for peer-dependency mismatches when running pnpm/npm with
strict peer deps and correct versions if necessary.
In `@examples/example-nextjs/src/app/`(home)/widgets/review.tsx:
- Around line 31-42: Wrap the avatar + name + date into a single grouped element
so the header's justify-between separates that identity block from the rating;
specifically, create a container (e.g., a flex div) that contains Avatar (with
AvatarImage and AvatarFallback) and the two <p> elements that use user.name and
the formatted createdAt, leaving the rating element as the other sibling so the
header's justify-between aligns the rating consistently; update the JSX around
Avatar, AvatarImage, AvatarFallback, user.name, and createdAt to reflect this
grouping.
In `@examples/example-nextjs/tsconfig.json`:
- Around line 23-25: Remove the "types": ["vitest/globals"] entry from the main
tsconfig.json to avoid ambient type pollution and restore default ambient types
(e.g., Node); then add a dedicated test-only tsconfig (e.g., tsconfig.test.json)
that extends the main tsconfig and sets "compilerOptions.types":
["vitest/globals", "node"] and an "include" for test files (e.g., **/*.test.ts,
**/*.test.tsx, vitest.config.ts); ensure Vitest is added to devDependencies so
the test-only config's "vitest/globals" type reference is valid.
In `@examples/example-rspack/src/review/review.tsx`:
- Around line 32-43: The avatar, name, and date are rendered as horizontal
siblings; wrap the textual metadata (the elements using user.name and createdAt
— currently the <p> elements) in a small column container (e.g., a div with a
vertical/flex-col layout) and place that container next to the Avatar component
so the name and formatted date stack vertically and remain compact; update the
JSX around Avatar, AvatarImage, AvatarFallback, the name paragraph, and the date
paragraph to nest the two <p> elements inside that new column container and
adjust surrounding layout classes (e.g., flex and spacing) accordingly.
In `@examples/example-webpack/src/review/review.tsx`:
- Around line 32-35: The AvatarImage is missing an alt attribute causing
redundant screen-reader announcements; update the Avatar usage (the AvatarImage
component inside the Avatar with AvatarFallback and user.avatar) to include an
explicit alt attribute (use alt="" to mark the image as decorative since the
user's name is rendered beside it via user.name / AvatarFallback). Ensure you
only add the alt prop on AvatarImage.
In `@package.json`:
- Line 65: The package.json currently lists "eslint": "^10.2.1" but the declared
engines.node range (engines.node) is ">=18.0.0", causing a compatibility
mismatch because ESLint v10 requires Node >=20.19.0; either update engines.node
to ">=20.19.0" (and any CI images/docs) to match ESLint v10, or downgrade eslint
to a v9.x release that supports Node 18—modify the package.json entry for
"eslint" or the engines.node field accordingly and ensure any related entries
(e.g., lockfile/CI Node versions) are updated to remain consistent.
In `@packages/inspector-babel-plugin/package.json`:
- Around line 66-68: The package.json currently declares an engines.node range
that is too low for the vitest dependency; update the "engines" -> "node" field
in package.json to require Node 20+ (e.g., ">=20.0.0") so it matches
vitest@^4.1.5's minimum, and ensure any engine-strict CI/test scripts will
respect the new requirement; verify the change alongside the "vitest" dependency
entry.
In `@packages/inspector-babel-plugin/vitest.config.ts`:
- Around line 10-11: testTimeout and hookTimeout are set to 5000 * 10000
(≈50_000_000 ms) which effectively disables timeouts; replace those
multiplications with reasonable explicit values (e.g., testTimeout: 30_000,
hookTimeout: 30_000) in the vitest config so hung tests fail fast, and apply the
same change to the other vitest configs that copy these variables (update the
testTimeout and hookTimeout symbols in the corresponding config files).
In `@packages/inspector-common/vitest.config.ts`:
- Around line 10-11: The configured timeouts testTimeout and hookTimeout in
vitest.config.ts are set to 5000 * 10000 (≈50,000,000ms); change them to a
realistic explicit value (for example 50_000 for 50 seconds) so tests/hooks
cannot hang for ~14 hours—update the testTimeout and hookTimeout assignments in
the vitest config to use the explicit millisecond constants you want (e.g.,
50_000) or a clearly named constant.
In `@packages/inspector-middleware/package.json`:
- Around line 52-54: The package declares vitest@^4.1.5 but the engines.node
field still allows Node 18, which is incompatible; update the engines field in
package.json (the "engines" -> "node" entry) to require Node 20 or higher (e.g.,
">=20" or ">=20.0.0") so the declared runtime matches Vitest 4's minimum
requirement and prevents running yarn test on unsupported Node 18 environments.
In `@packages/inspector-middleware/vitest.config.ts`:
- Around line 10-11: The testTimeout and hookTimeout values in vitest.config.ts
are accidentally set to 5000 * 10000 (~13.9 hours); replace those expressions
with explicit, reasonable millisecond bounds (for example 30000 for 30s or
120000 for 2m) to prevent CI workers from being held indefinitely; update the
testTimeout and hookTimeout assignments in the exported Vitest config object so
they use the chosen numeric literal and ensure any related comments reflect the
new limit.
In `@packages/inspector/vitest.config.ts`:
- Around line 10-11: The testTimeout and hookTimeout values are set to an
excessively large value (5000 * 10000); update the constants used in the Vitest
config (testTimeout and hookTimeout) to a reasonable timeout such as 50_000 (50
seconds) instead of the current multiplication expression so CI won't hang for
hours; locate the settings in vitest.config.ts where testTimeout and hookTimeout
are defined and replace the expressions with the new numeric timeout value
(e.g., 50_000) for both keys.
In `@packages/next-inspector/package.json`:
- Around line 74-80: The package.json currently allows Node >=18.0.0 which is
incompatible with Next.js 16 and Vitest 4; update the engines field in
package.json to require Node 20.9.0 or newer (e.g., "node": ">=20.9.0") so
consumers cannot install/run with Node 18; locate the "engines" entry in
packages/next-inspector/package.json and change its node constraint accordingly,
and update any related CI/workflow configs that reference the old Node version
if present.
In `@packages/next-inspector/vitest.config.ts`:
- Around line 10-11: The timeouts testTimeout and hookTimeout in
vitest.config.ts are set to 5000 * 10000 (~13.9 hours); change them to realistic
values (e.g., 50_000 for 50 seconds or another reasonable ms value) so
tests/hooks cannot hang for hours — replace the overly large multiplication with
an explicit millisecond constant and ensure both testTimeout and hookTimeout use
the corrected value.
---
Outside diff comments:
In `@examples/example-rspack/package.json`:
- Around line 58-73: The production browserslist in package.json is too broad
for Tailwind CSS v4; update the "browserslist" production target to only include
modern browsers that meet Tailwind v4 minimum requirements (e.g., Chrome 111+,
Safari 16.4+, Firefox 128+) or else revert to Tailwind v3; locate the
"browserslist" object in package.json and replace the production array
(currently ">0.2%, not dead, not op_mini all") with a narrowed set of targets
that reflect Chrome >=111, Safari >=16.4, and Firefox >=128, ensuring build
tools and PostCSS use the new targets.
---
Nitpick comments:
In `@crates/inspector-swc-plugin/package.json`:
- Around line 48-49: The two SWC dependency ranges are inconsistent—@swc/core is
"~1.15.30" while `@swc/wasm-web` is "^1.15.30"; change the `@swc/wasm-web` entry to
"~1.15.30" so both `@swc/core` and `@swc/wasm-web` use the same patch-locked range,
and update lockfile/install (npm/yarn) afterward to ensure the resolved versions
remain aligned.
In `@packages/inspector-babel-plugin/vitest.config.ts`:
- Around line 4-7: Replace the native resolve.tsconfigPaths usage with the
official vite-tsconfig-paths plugin: import viteTsconfigPaths from
'vite-tsconfig-paths' and add viteTsconfigPaths() to the plugins array in
vitest.config.ts, and remove or disable resolve: { tsconfigPaths: true } (apply
the same change to the other vitest.config.ts files mentioned) so tsconfig path
aliases are resolved via the plugin for monorepo consistency.
In `@packages/inspector-common/package.json`:
- Line 48: The `@types/node` devDependency currently pins Node typings to ^25.6.0
which is inconsistent with the package's supported runtime (Node >=18.0.0);
update the "@types/node" entry in package.json to a types version that matches
Node 18 (for example ^18.x or a specific 18.y.z like ^18.16.0) so typechecks
reflect the supported runtime and avoid accidental usage of newer Node APIs;
ensure the change is applied where "@types/node" appears (lines referencing that
dependency) and run the typecheck to verify no new type errors.
In `@packages/inspector-component/package.json`:
- Around line 69-72: The peerDependencies currently pin "react" and "react-dom"
to ">=19.2.5" which unnecessarily rejects 19.2.3/19.2.4 consumers; update the
"peerDependencies" entries for the keys "react" and "react-dom" to a broader
range (for example ">=19.2.3" or a caret range like "^19.2.3" or ">=19.2.3 <20")
so consumers on 19.2.3/19.2.4 are allowed, and keep any requirement for 19.2.5
limited to devDependencies/test setup only.
- Line 50: The package.json currently depends on "@types/node" at a Node 25
typings level which is inconsistent with the package's supported runtime (Node
>=18.0.0); update the "@types/node" entry to a version that targets Node 18 (for
example to a caret range like ^18.x or a specific 18.x.y release) so the typings
match the engine target, and ensure any other occurrences/entries referencing
Node versions (e.g., the "engines" field) remain consistent; after changing the
"@types/node" version, run the typechecker to verify no new type errors are
introduced.
In `@packages/inspector/package.json`:
- Line 48: package.json currently depends on "@types/node": "^25.6.0" while
"engines.node" still advertises ">=18.0.0", which allows Node 25-only types to
slip through; either pin "@types/node" to the lowest supported runtime (e.g.,
change "@types/node" to a version matching Node 18) OR raise "engines.node" to
the minimum Node version that matches the types (and update CI matrix
accordingly); update the package.json "dependencies/devDependencies" entry for
"@types/node" and/or the "engines.node" field and adjust CI job node versions so
types and runtime are aligned.
In `@website/package.json`:
- Around line 49-52: Add an engines constraint to package.json to require Node
20 for local development: insert an "engines" object at the package.json root
(near existing deps like "@docusaurus/core") with e.g. "node": ">=20.0.0
<21.0.0" so the project explicitly documents and enforces the Node.js 20
requirement.
🪄 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: 70c02c5b-90d6-4cd1-99ba-6b16fa4bc248
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.lockyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (63)
.changeset/violet-pants-fold.mdCargo.tomlcrates/inspector-swc-plugin/package.jsoncrates/inspector-swc-plugin/tsconfig.build.jsoncrates/inspector-swc-plugin/tsconfig.jsoncrates/inspector-swc-plugin/vitest.config.tsexamples/example-nextjs/README.mdexamples/example-nextjs/package.jsonexamples/example-nextjs/src/app/(home)/page.tsxexamples/example-nextjs/src/app/(home)/widgets/review.tsxexamples/example-nextjs/src/app/layout.tsxexamples/example-nextjs/src/components/Providers/ProviderWrapper.tsxexamples/example-nextjs/src/styles/globals.cssexamples/example-nextjs/src/theme/hero.tsexamples/example-nextjs/tsconfig.jsonexamples/example-rspack/global.d.tsexamples/example-rspack/package.jsonexamples/example-rspack/rspack.config.mjsexamples/example-rspack/src/App.tsxexamples/example-rspack/src/index.cssexamples/example-rspack/src/main.tsxexamples/example-rspack/src/review/review.tsxexamples/example-rspack/tsconfig.jsonexamples/example-webpack/global.d.tsexamples/example-webpack/package.jsonexamples/example-webpack/src/App.tsxexamples/example-webpack/src/index.cssexamples/example-webpack/src/main.tsxexamples/example-webpack/src/review/review.tsxexamples/example-webpack/src/theme/hero.tsexamples/example-webpack/tsconfig.jsonpackage.jsonpackages/inspector-babel-plugin/package.jsonpackages/inspector-babel-plugin/tsconfig.jsonpackages/inspector-babel-plugin/vitest.config.tspackages/inspector-common/package.jsonpackages/inspector-common/tsconfig.jsonpackages/inspector-common/vitest.config.tspackages/inspector-component/package.jsonpackages/inspector-component/tsconfig.jsonpackages/inspector-component/vitest.config.tspackages/inspector-middleware/package.jsonpackages/inspector-middleware/tsconfig.jsonpackages/inspector-middleware/vitest.config.tspackages/inspector/package.jsonpackages/inspector/src/events/click-element-event.tspackages/inspector/src/events/hover-element-event.tspackages/inspector/src/events/pointer-down-event.tspackages/inspector/src/hooks/use-start-inspecting.tspackages/inspector/src/hooks/use-stop-inspecting.tspackages/inspector/src/types/type-inspector.tspackages/inspector/tsconfig-client.build.jsonpackages/inspector/tsconfig.build.jsonpackages/inspector/tsconfig.jsonpackages/inspector/vitest.config.tspackages/next-inspector/package.jsonpackages/next-inspector/src/api/get-inspector-config.tspackages/next-inspector/tsconfig.jsonpackages/next-inspector/vitest.config.tstsconfig.base.jsontsconfig.jsonwebsite/package.jsonwebsite/tsconfig.json
💤 Files with no reviewable changes (16)
- crates/inspector-swc-plugin/tsconfig.build.json
- crates/inspector-swc-plugin/tsconfig.json
- packages/inspector-component/tsconfig.json
- examples/example-nextjs/src/components/Providers/ProviderWrapper.tsx
- website/tsconfig.json
- examples/example-webpack/tsconfig.json
- tsconfig.json
- tsconfig.base.json
- packages/next-inspector/tsconfig.json
- packages/inspector-babel-plugin/tsconfig.json
- packages/inspector-common/tsconfig.json
- packages/inspector/tsconfig.json
- examples/example-rspack/tsconfig.json
- examples/example-webpack/src/theme/hero.ts
- examples/example-nextjs/src/theme/hero.ts
- packages/inspector-middleware/tsconfig.json
| swc = { version = "62.0.0", default-features = false } | ||
| swc_common = { version = "21.0.1", default-features = false } | ||
| swc_config = { version = "4.0.0" , default-features = false} | ||
| swc_core = { version = "64.0.0", default-features = false, features = ["parallel_rayon"] } | ||
| swc_ecma_minifier = { version = "52.0.0", default-features = false } | ||
| swc_error_reporters = { version = "23.0.0", default-features = false } | ||
| swc_html = { version = "33.0.0", default-features = false} | ||
| swc_html_minifier = { version = "52.0.0", default-features = false } | ||
| swc_node_comments = { version = "21.0.0", default-features = false} | ||
| swc_parallel = { version = "1.3.0", default-features = false, features = ["rayon"] } | ||
| swc_ecma_ast = { version = "19.0.0", default-features = false} | ||
| swc_ecma_utils = { version = "25.0.0", default-features = false} | ||
| swc_ecma_visit = { version = "19.0.0", default-features = false} | ||
| swc_ecma_ast = { version = "23.0.0", default-features = false} | ||
| swc_ecma_utils = { version = "29.1.0", default-features = false} | ||
| swc_ecma_visit = { version = "23.0.0", default-features = false} | ||
| swc_plugin_macro = { version = "1.1.0", default-features = false } | ||
| swc_atoms = { version = "9.0.0", default-features = false} | ||
| swc_cached = { version = "2.0.0", default-features = false} | ||
| swc_ecma_transforms_react = { version = "38.0.0", default-features = false} | ||
| swc_ecma_transforms_testing = { version = "38.0.0", default-features = false} | ||
| swc_ecma_transforms_react = { version = "46.0.0", default-features = false} | ||
| swc_ecma_transforms_testing = { version = "46.0.0", default-features = false} | ||
| swc_trace_macro = { version = "2.0.0", default-features = false} | ||
| testing = { version = "19.0.0", default-features = false} | ||
| convert_case = { version = "0.10.0", default-features = false} | ||
| testing = { version = "22.0.0", default-features = false} | ||
| convert_case = { version = "0.11.0", default-features = false} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# 1. Confirm cargo resolves without duplicated swc_* crates and plugin builds.
# (build may fail in sandbox if it can't fetch — focus on resolution / tree.)
cargo tree -p swc_core --edges=no-dev 2>&1 | head -80
cargo tree 2>&1 | rg -n '^\S*swc_' | sort -u
# 2. Confirm swc_core 64.0.0 actually requires the pinned sibling versions.
curl -s https://crates.io/api/v1/crates/swc_core/64.0.0/dependencies | \
jq '.dependencies[] | select(.crate_id|startswith("swc_")) | {crate_id, req}'
# 3. Sanity-check that swc_ecma_utils 29.1.0 exists and isn't a typo.
curl -s https://crates.io/api/v1/crates/swc_ecma_utils | \
jq '.versions[0:6] | .[] | {num, created_at}'
# 4. Find which host-runtime versions the plugin will be loaded by (README/docs).
rg -nP '(`@swc/core`|next|rspack)\b.*\b\d+\.\d+' -g '!**/node_modules/**' -g '*.md' -g 'package.json' | head -40Repository: hyperse-io/code-inspector
Length of output: 5051
🌐 Web query:
What swc_plugin_runner / host runtime versions are compatible with swc_core 64.0.0 WASM plugins per plugins.swc.rs?
💡 Result:
No specific compatibility information found for swc_core 64.0.0 WASM plugins on plugins.swc.rs or official docs. swc_core latest released version is 63.1.3 (as of 2026-04-14). Compatibility is determined by matching swc_core versions between plugins (built with specific swc_core) and host runtimes (@swc/core, Next.js, Rspack). Use https://plugins.swc.rs/ to select runtime/framework version and find compatible plugin swc_core versions. For plugins built with swc_core >=47, enable swc_ast_unknown cfg for partial backward compatibility across @swc/core versions.
Citations:
- 1: https://swc.rs/docs/plugin/ecmascript/compatibility
- 2: https://swc.rs/docs/plugin/selecting-swc-core
- 3: SWC Plugin Compatibility Explanation lingui/swc-plugin#179
- 4: https://crates.io/crates/swc_core
- 5: https://plugins.swc.rs/versions/range
🏁 Script executed:
# 1. Check what swc_core version `@swc/core` 1.15.30 bundles
curl -s https://registry.npmjs.org/@swc/core/1.15.30 | \
jq '.dependencies, .optionalDependencies' 2>/dev/null || echo "Package not found"
# 2. Check if `@swc/core` 1.15 or 2.x exists to understand versioning
curl -s https://registry.npmjs.org/@swc/core | \
jq '.versions | keys[-20:]' 2>/dev/null
# 3. Check Next.js 16.2.4 and Rspack 2.0.0 bundled/peer dependencies for `@swc/core`
curl -s https://registry.npmjs.org/next/16.2.4 | \
jq '.dependencies["@swc/core"] // .peerDependencies["@swc/core"] // "not found"'
curl -s https://registry.npmjs.org/@rspack/core/2.0.0 | \
jq '.dependencies["@swc/core"] // .peerDependencies["@swc/core"] // "not found"'Repository: hyperse-io/code-inspector
Length of output: 1121
🌐 Web query:
@swc/core 1.15.30 swc_core version bundled 64.0.0
💡 Result:
@swc/core version 1.15.30 bundles swc_core version 64.0.0. This is a nightly release (e.g., 1.15.30-nightly-20260418.1 for the linux-x64-gnu platform), as evidenced by Snyk indexing the package published around 2026-04-19. Multiple GitHub releases from April 19, 18, and earlier explicitly tag "swc_core v64.0.0", aligning with the pattern seen in stable releases like 1.15.24 bundling v62.0.0 and 1.15.21 with v59.0.1. The swc_core crate's latest stable is v63.1.3 (crates.io, updated 2026-04-14), confirming v64.0.0 is from a recent nightly build used in @swc/core's platform-specific binaries.
Citations:
- 1: https://security.snyk.io/package/npm/%40swc%2Fcore-linux-x64-gnu/1.15.30-nightly-20260418.1
- 2: https://github.com/swc-project/swc/releases
- 3: https://crates.io/crates/swc_core
🏁 Script executed:
# Check Next.js 16.2.4 bundled swc by looking at package tarball contents or release info
curl -s https://registry.npmjs.org/next/16.2.4 | jq '.dist' | head -20
# Try checking the published changelog or release info
curl -s 'https://api.github.com/repos/vercel/next.js/releases' | \
jq '.[] | select(.tag_name=="v16.2.4") | {tag_name, body}' | head -100
# Check Rspack 2.0.0 similarly
curl -s 'https://api.github.com/repos/web-infra-dev/rspack/releases' | \
jq '.[] | select(.tag_name | contains("2.0.0")) | {tag_name, body}' | head -100Repository: hyperse-io/code-inspector
Length of output: 50468
🌐 Web query:
Next.js 16.2.4 bundled @swc/core version SWC compiler
💡 Result:
Next.js 16.2.4 bundles the SWC compiler via its internal @next/swc package, which uses swc_core version likely around 56.0.0 or later (based on recent updates in the repository). The exact version is specified in the Cargo.toml file of the next.js monorepo at the v16.2.4 tag, typically swc_core = { version = "56.x.x", features = [...] }. No npm @swc/core package is directly bundled; Next.js uses native Rust-based SWC binaries compiled from swc_core. To check the precise version in a project, inspect node_modules/.pnpm/next-swc@16.2.4/node_modules/next-swc/native/* or the Cargo.lock file in the source.
Citations:
- 1: build: Update
swc_coretov16.0.0vercel/next.js#76414 - 2: vercel/next.js@2275bd8
- 3: How can I check which version of SWC is being used by Next.js? vercel/next.js#81585
- 4: https://github.com/vercel/next.js/blob/v16.2.0-canary.84/Cargo.toml
- 5: vercel/next.js@1fac9a1
- 6: vercel/next.js@v16.1.5...v16.1.6
🌐 Web query:
Rspack 2.0.0 @swc/core bundled version
💡 Result:
Rspack 2.0.0 bundles @swc/core version 62.x (exact patch version not explicitly stated in sources, but the final pre-release bump was to swc_core 62 in PR #13602, merged before the 2.0.0 release on 2026-04-22).
Citations:
- 1: https://newreleases.io/project/npm/@rspack/core/release/2.0.0
- 2: https://github.com/web-infra-dev/rspack/releases
- 3: chore: bump
swc_corefrom 56 to 58 web-infra-dev/rspack#13164 - 4: chore: bump swc_core from 55 to 56 and swc-experimental from 0.4.1 to 0.5.0 web-infra-dev/rspack#12906
Critical: swc_core 64.0.0 is incompatible with Next.js 16.2.4 and Rspack 2.0.0 bundled WASM plugin hosts.
The README documents Next.js >=16.1.1 and Rspack >=1.6.0 support, and examples show Next.js 16.2.4 and Rspack 2.0.0. However:
- Next.js 16.2.4 bundles swc_core ~56.x via
@next/swc - Rspack 2.0.0 bundles
@swc/core62.x (swc_core 62)
Neither version is compatible with WASM plugins built against swc_core 64.0.0. This mismatch will cause failed to run Wasm plugin transform errors at runtime. Verify the actual swc_core versions shipped by your targeted Next.js and Rspack versions before merging. If this is an intentional toolchain jump, update the version constraints in the README and examples accordingly.
The internal Cargo.toml pins are consistent: all match swc_core 64.0.0's exact dependency requirements (swc_ecma_utils 29.1.0 is correct, not a typo). Cargo will resolve without duplication if dependencies fetch successfully.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Cargo.toml` around lines 25 - 45, The Cargo.toml pins swc_core = "64.0.0"
which is incompatible with the swc versions bundled by the targeted Next.js
(≈56.x) and Rspack (≈62.x) releases; to fix, change the swc_core dependency (and
any tightly coupled swc_* entries that require exact swc_core compatibility such
as swc_ecma_utils, swc_core, swc, swc_parallel) to a version that matches the
bundled runtime (e.g., align to 62.x for Rspack 2.0.0 or to the specific
`@next/swc` version for Next.js 16.2.4) OR explicitly document and bump the
README/examples to require the newer toolchain if you intentionally want 64.0.0;
update the swc_core declaration and any sibling swc_* pins in Cargo.toml (and
adjust README/example version constraints) so runtime WASM plugin ABI matches
the shipped swc.
| "rimraf": "^6.1.3", | ||
| "typescript": "^6.0.3", | ||
| "vitest": "^4.1.5" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd crates/inspector-swc-plugin && cat -n package.json | grep -A 10 -B 10 "engines"Repository: hyperse-io/code-inspector
Length of output: 592
🌐 Web query:
vitest 4.1.5 node version requirements
💡 Result:
Vitest 4.1.5 requires Node.js >= 20.0.0.
Citations:
- 1: https://vitest.dev/guide/migration.html
- 2: https://v4.vitest.dev/guide/migration
- 3: https://npmx.dev/package/vitest/v/4.1.0
- 4: https://www.npmjs.com/package/vitest
- 5: https://github.com/vitest-dev/vitest
Align the development engine with Vitest 4 Node requirements.
vitest@^4.1.5 requires Node 20+, but this package advertises Node >=18.0.0. This mismatch can cause installation or runtime failures in Node 18-19 environments. Update the engines declaration:
"engines": {
- "node": ">=18.0.0"
+ "node": ">=20.0.0"
},This applies to lines 59-60.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@crates/inspector-swc-plugin/package.json` around lines 55 - 57, The package
advertises Node ">=18.0.0" but depends on vitest@^4.1.5 which requires Node 20+,
so update the engines field in package.json to require Node >=20.0.0; open the
package.json entry for "engines" and change the Node version constraint
(reference: the vitest dependency and the "engines" field) so the declared Node
range matches Vitest's requirements and avoids install/runtime failures on Node
18/19.
| "scripts": { | ||
| "dev": "RUST_BACKTRACE=full next dev --turbopack", | ||
| "build": "next build", | ||
| "start": "next start", | ||
| "lint": "next lint" | ||
| "start": "next start" | ||
| }, |
There was a problem hiding this comment.
Inconsistency: lint script removed, but eslint + shareable config were added as devDependencies.
The scripts block drops lint (previously next lint), yet this PR simultaneously adds eslint (^10.2.1) and @hyperse/eslint-config-hyperse (^1.7.2) to devDependencies. As-is, there is no npm entry point to run ESLint in this example, so either:
- the script was dropped unintentionally and should be restored (now that
next lintis removed in Next.js 15+, it should invokeeslintdirectly), or - the two new devDependencies are unused and should be removed to keep
node_moduleslean.
🔧 Suggested fix — add an explicit lint script
"scripts": {
"dev": "RUST_BACKTRACE=full next dev --turbopack",
"build": "next build",
- "start": "next start"
+ "start": "next start",
+ "lint": "eslint ."
},Also applies to: 44-44, 58-58
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/example-nextjs/package.json` around lines 16 - 20, The package.json
scripts block removed the "lint" entry while adding eslint and
`@hyperse/eslint-config-hyperse` as devDependencies; restore a lint script in the
scripts object (e.g., add a "lint" script that runs eslint across the project
files such as "eslint . --ext .js,.jsx,.ts,.tsx" or similar) so the new
devDependencies are actually usable, and ensure the project's ESLint config
references `@hyperse/eslint-config-hyperse`; alternatively remove those two
devDependencies if you prefer not to provide a lint task.
| "css-loader": "^7.1.2", | ||
| "autoprefixer": "^10.5.0", | ||
| "css-loader": "^7.1.4", | ||
| "eslint": "^10.2.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# 1) Verify tsconfig in this example handles the TS 6 defaults explicitly.
fd -t f 'tsconfig*.json' examples/example-nextjs -x cat {}
# 2) Check the engines field / Node floor and any related CI config.
fd -t f 'package.json' -d 3 -x jq -r '{name: .name, engines: .engines}' {} \; | head -40
# 3) Look at the shareable config to see what ESLint plugins will be pulled in transitively.
rg -nP --type=json '"eslint-' -C1 -g '!**/node_modules/**'
# 4) Confirm no leftover `next lint` references in docs / CI.
rg -nP '\bnext\s+lint\b'Repository: hyperse-io/code-inspector
Length of output: 1553
🏁 Script executed:
# Check actual ESLint and TypeScript versions in examples/example-nextjs
cat examples/example-nextjs/package.json | grep -A 30 '"dependencies"\|"devDependencies"' | grep -E '"eslint"|"typescript"'Repository: hyperse-io/code-inspector
Length of output: 120
🏁 Script executed:
# Check for ESLint configuration in the example
fd -t f '\\.eslintrc*' examples/example-nextjsRepository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Look for any eslint-config or eslint-plugin dependencies in the shared config
fd -t f 'package.json' examples/example-nextjs -x cat {} | jq '.dependencies, .devDependencies' 2>/dev/nullRepository: hyperse-io/code-inspector
Length of output: 1440
🏁 Script executed:
# Check if there's a GitHub Actions CI config that specifies Node version
fd -t f '*.yml' '.github/workflows' -x cat {} 2>/dev/null | head -100Repository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Check the `@hyperse/eslint-config-hyperse` package to see what ESLint plugins it declares
fd -t f 'package.json' -path '*/hyperse/eslint-config*' -x cat {}Repository: hyperse-io/code-inspector
Length of output: 237
🏁 Script executed:
# Look for CI configuration in other locations
find . -type f \( -name '*.yml' -o -name '*.yaml' \) | grep -E '(github|gitlab|circleci|workflow)' | head -20Repository: hyperse-io/code-inspector
Length of output: 914
🏁 Script executed:
# Check if eslint-plugin-react is anywhere in dependencies
rg -P 'eslint-plugin-react' --type=jsonRepository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Verify the actual issue with Node version and ESLint 10 compatibility
rg -P 'node.*20|20.*node' examples/example-nextjs/package.jsonRepository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Check the main CI workflows for Node version requirements
cat .github/workflows/ci-inspector.yml | grep -A 5 -B 5 'node-version\|node_version'Repository: hyperse-io/code-inspector
Length of output: 757
🏁 Script executed:
# Look for the eslint config package definition
find . -type f -name 'package.json' | xargs grep -l 'eslint-config-hyperse' | head -5Repository: hyperse-io/code-inspector
Length of output: 253
🏁 Script executed:
# Check if eslint-plugin-react is in any dependencies across the monorepo
rg 'eslint-plugin-react' -g '!node_modules'Repository: hyperse-io/code-inspector
Length of output: 1064
🏁 Script executed:
# Examine the shared eslint config to see what plugins it includes
fd 'package.json' | xargs grep -l 'eslint-config-hyperse' | head -1 | xargs -I {} dirname {} | xargs -I {} find {} -name 'index.js' -o -name '.eslintrc*'Repository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Find the eslint-config-hyperse package location and check its configuration
fd -t f 'package.json' | xargs grep -l '"name".*"eslint-config-hyperse"' 2>/dev/nullRepository: hyperse-io/code-inspector
Length of output: 53
🏁 Script executed:
# Check what's in the eslint config directory
find . -type d -name 'eslint-config*' | grep -v node_modules | head -5Repository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Look at the root package.json to see how eslint-config-hyperse is configured
cat packages/eslint-config-hyperse/package.json 2>/dev/null || echo "File not found, searching..."Repository: hyperse-io/code-inspector
Length of output: 97
🏁 Script executed:
# Search for the actual eslint config content in the repo
rg -l 'eslint-config-hyperse' --type json | head -5 | xargs -I {} dirname {} | head -1 | xargs -I {} find {} -type fRepository: hyperse-io/code-inspector
Length of output: 50439
Add missing Node engine constraint and fix TypeScript configuration for v6 compatibility.
This PR bundles ESLint 10.2.1 (requires Node ≥ 20.19.0) and TypeScript 6.0.3 (requires explicit "types": ["node"] in tsconfig) without addressing their new requirements:
- package.json: Missing
enginesfield entirely. CI uses generic20.x, which may not satisfy ESLint 10's ≥ 20.19.0 requirement. - tsconfig.json: Has
"types": ["vitest/globals"]but TypeScript 6 requires"types": ["node"]to resolve Node types; the new empty default will cause missing identifier errors. - tsconfig.json: No explicit
rootDirset; confirm if it's needed given your build setup. - ESLint config: The shared config
@hyperse/eslint-config-hypersepulls ineslint-plugin-react-*variants via transitive dependencies. Verify no peer-dependency conflicts in strict-peer-dep mode (pnpm/npm).
Update examples/example-nextjs/package.json to set "engines": { "node": ">=20.19.0" } and adjust tsconfig types accordingly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/example-nextjs/package.json` at line 58, Add a Node engine
constraint and make the TypeScript config v6-compatible: update package.json to
include an "engines" entry with "node": ">=20.19.0" so ESLint 10.2.1's Node
requirement is satisfied; update tsconfig.json to set "types": ["node",
"vitest/globals"] (or include "node" alongside existing "vitest/globals") and
consider adding an explicit "rootDir" if your build expects one; finally, review
the ESLint config dependency set (the shared config
`@hyperse/eslint-config-hyperse` and any eslint-plugin-react-* transitive deps)
for peer-dependency mismatches when running pnpm/npm with strict peer deps and
correct versions if necessary.
| <Avatar> | ||
| <AvatarImage src={user.avatar} /> | ||
| <AvatarFallback>{user.name.charAt(0)}</AvatarFallback> | ||
| </Avatar> | ||
| <p className="text-default-900 font-medium">{user.name}</p> | ||
| <p className="text-default-500"> | ||
| {new Intl.DateTimeFormat('en-US', { | ||
| month: 'long', | ||
| day: 'numeric', | ||
| year: 'numeric', | ||
| }).format(new Date(createdAt))} | ||
| </p> |
There was a problem hiding this comment.
Group the avatar, name, and date before the rating.
These elements are now direct justify-between children, so the header spreads avatar/name/date/rating across the full width. This diverges from the Webpack example’s grouped identity block and makes the rating alignment unstable.
Proposed fix
- <Avatar>
- <AvatarImage src={user.avatar} />
- <AvatarFallback>{user.name.charAt(0)}</AvatarFallback>
- </Avatar>
- <p className="text-default-900 font-medium">{user.name}</p>
- <p className="text-default-500">
- {new Intl.DateTimeFormat('en-US', {
- month: 'long',
- day: 'numeric',
- year: 'numeric',
- }).format(new Date(createdAt))}
- </p>
+ <div className="flex items-center gap-2">
+ <Avatar>
+ <AvatarImage src={user.avatar} />
+ <AvatarFallback>{user.name.charAt(0)}</AvatarFallback>
+ </Avatar>
+ <p className="text-default-900 font-medium">{user.name}</p>
+ <p className="text-default-500">
+ {new Intl.DateTimeFormat('en-US', {
+ month: 'long',
+ day: 'numeric',
+ year: 'numeric',
+ }).format(new Date(createdAt))}
+ </p>
+ </div>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <Avatar> | |
| <AvatarImage src={user.avatar} /> | |
| <AvatarFallback>{user.name.charAt(0)}</AvatarFallback> | |
| </Avatar> | |
| <p className="text-default-900 font-medium">{user.name}</p> | |
| <p className="text-default-500"> | |
| {new Intl.DateTimeFormat('en-US', { | |
| month: 'long', | |
| day: 'numeric', | |
| year: 'numeric', | |
| }).format(new Date(createdAt))} | |
| </p> | |
| <div className="flex items-center gap-2"> | |
| <Avatar> | |
| <AvatarImage src={user.avatar} /> | |
| <AvatarFallback>{user.name.charAt(0)}</AvatarFallback> | |
| </Avatar> | |
| <p className="text-default-900 font-medium">{user.name}</p> | |
| <p className="text-default-500"> | |
| {new Intl.DateTimeFormat('en-US', { | |
| month: 'long', | |
| day: 'numeric', | |
| year: 'numeric', | |
| }).format(new Date(createdAt))} | |
| </p> | |
| </div> |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@examples/example-nextjs/src/app/`(home)/widgets/review.tsx around lines 31 -
42, Wrap the avatar + name + date into a single grouped element so the header's
justify-between separates that identity block from the rating; specifically,
create a container (e.g., a flex div) that contains Avatar (with AvatarImage and
AvatarFallback) and the two <p> elements that use user.name and the formatted
createdAt, leaving the rating element as the other sibling so the header's
justify-between aligns the rating consistently; update the JSX around Avatar,
AvatarImage, AvatarFallback, user.name, and createdAt to reflect this grouping.
| "rimraf": "^6.1.3", | ||
| "typescript": "^6.0.3", | ||
| "vitest": "^4.1.5" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd packages/inspector-middleware && cat -n package.json | sed -n '40,70p'Repository: hyperse-io/code-inspector
Length of output: 1020
🌐 Web query:
Vitest 4 Node.js requirement minimum version
💡 Result:
Vitest 4 requires Node.js version 20.0.0 or higher.
Citations:
- 1: https://vitest.dev/guide/migration.html
- 2: https://vitest.dev/guide/
- 3: Migration documentation doesn't specify Vite version required. vitest-dev/vitest#9646
- 4: https://github.com/vitest-dev/vitest/releases/tag/v4.0.0
Align the development engine with Vitest 4.
vitest@^4.1.5 is now in the package toolchain, while engines.node still permits Node 18. Vitest 4 requires Node 20+, so yarn test can fail in Node 18 environments that this package currently advertises as supported. Update the engines field to reflect the actual minimum requirement:
"engines": {
- "node": ">=18.0.0"
+ "node": ">=20.0.0"
},🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/inspector-middleware/package.json` around lines 52 - 54, The package
declares vitest@^4.1.5 but the engines.node field still allows Node 18, which is
incompatible; update the engines field in package.json (the "engines" -> "node"
entry) to require Node 20 or higher (e.g., ">=20" or ">=20.0.0") so the declared
runtime matches Vitest 4's minimum requirement and prevents running yarn test on
unsupported Node 18 environments.
| testTimeout: 5000 * 10000, | ||
| hookTimeout: 5000 * 10000, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n packages/inspector-middleware/vitest.config.tsRepository: hyperse-io/code-inspector
Length of output: 576
🏁 Script executed:
# Check for comments or documentation about timeouts
grep -r "testTimeout\|hookTimeout" packages/inspector-middleware/ --include="*.ts" --include="*.js" --include="*.md"Repository: hyperse-io/code-inspector
Length of output: 224
🏁 Script executed:
# Check git history to see if this was intentional or accidental
git log -p --follow -S "5000 * 10000" -- packages/inspector-middleware/vitest.config.ts | head -100Repository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Check if there are other vitest configs in the repo to compare patterns
fd -t f "vitest.config\|vite.config" . --exclude node_modulesRepository: hyperse-io/code-inspector
Length of output: 51
🏁 Script executed:
# Check typical vitest defaults to provide context
grep -r "timeout" packages/ --include="*.md" -A 2 -B 2 | head -50Repository: hyperse-io/code-inspector
Length of output: 51
Avoid 13-hour test timeouts.
5000 * 10000 equals 50,000,000ms (~13.9 hours). A hung test or hook can occupy CI workers almost indefinitely. Replace with an explicit, bounded value.
Proposed fix
- testTimeout: 5000 * 10000,
- hookTimeout: 5000 * 10000,
+ testTimeout: 50_000,
+ hookTimeout: 50_000,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| testTimeout: 5000 * 10000, | |
| hookTimeout: 5000 * 10000, | |
| testTimeout: 50_000, | |
| hookTimeout: 50_000, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/inspector-middleware/vitest.config.ts` around lines 10 - 11, The
testTimeout and hookTimeout values in vitest.config.ts are accidentally set to
5000 * 10000 (~13.9 hours); replace those expressions with explicit, reasonable
millisecond bounds (for example 30000 for 30s or 120000 for 2m) to prevent CI
workers from being held indefinitely; update the testTimeout and hookTimeout
assignments in the exported Vitest config object so they use the chosen numeric
literal and ensure any related comments reflect the new limit.
| testTimeout: 5000 * 10000, | ||
| hookTimeout: 5000 * 10000, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n packages/inspector/vitest.config.tsRepository: hyperse-io/code-inspector
Length of output: 576
🏁 Script executed:
fd 'vitest.config' --type fRepository: hyperse-io/code-inspector
Length of output: 401
🏁 Script executed:
for file in packages/inspector-middleware/vitest.config.ts packages/inspector-common/vitest.config.ts packages/inspector-component/vitest.config.ts packages/next-inspector/vitest.config.ts; do
echo "=== $file ==="
grep -A 2 -B 2 "testTimeout\|hookTimeout" "$file" 2>/dev/null || echo "No timeout config found"
doneRepository: hyperse-io/code-inspector
Length of output: 1005
Excessive test timeouts cause CI hangs.
5000 * 10000 equals 50,000,000ms (~13.9 hours), which will cause CI failures to surface much slower when a test or hook hangs. Replace with a reasonable timeout value like 50_000 (50 seconds).
Proposed fix
- testTimeout: 5000 * 10000,
- hookTimeout: 5000 * 10000,
+ testTimeout: 50_000,
+ hookTimeout: 50_000,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| testTimeout: 5000 * 10000, | |
| hookTimeout: 5000 * 10000, | |
| testTimeout: 50_000, | |
| hookTimeout: 50_000, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/inspector/vitest.config.ts` around lines 10 - 11, The testTimeout
and hookTimeout values are set to an excessively large value (5000 * 10000);
update the constants used in the Vitest config (testTimeout and hookTimeout) to
a reasonable timeout such as 50_000 (50 seconds) instead of the current
multiplication expression so CI won't hang for hours; locate the settings in
vitest.config.ts where testTimeout and hookTimeout are defined and replace the
expressions with the new numeric timeout value (e.g., 50_000) for both keys.
| "next": "^16.2.4", | ||
| "npm-run-all": "^4.1.5", | ||
| "react": "^19.2.0", | ||
| "react-dom": "^19.2.3", | ||
| "rimraf": "^6.1.2", | ||
| "typescript": "^5.9.3", | ||
| "vitest": "^4.0.16" | ||
| "react": "^19.2.5", | ||
| "react-dom": "^19.2.5", | ||
| "rimraf": "^6.1.3", | ||
| "typescript": "^6.0.3", | ||
| "vitest": "^4.1.5" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat packages/next-inspector/package.json | sed -n '74,105p'Repository: hyperse-io/code-inspector
Length of output: 857
🌐 Web query:
Next.js 16 Node.js version requirement official documentation
💡 Result:
Next.js 16 requires Node.js version 20.9.0 or higher (20.9+). Node.js 18 is no longer supported.
Citations:
- 1: https://nextjs.org/docs/app/guides/upgrading/version-16
- 2: https://nextjs.org/blog/next-16
- 3: https://nextjs.org/docs/app/getting-started/installation
🌐 Web query:
Vitest 4 Node.js version requirement
💡 Result:
Vitest 4 requires Node.js version >= 20.0.0.
Citations:
- 1: https://vitest.dev/guide/migration.html
- 2: https://v4.vitest.dev/guide/migration
- 3: https://vitest.dev/guide/
- 4: Migration documentation doesn't specify Vite version required. vitest-dev/vitest#9646
- 5: https://github.com/vitest-dev/vitest/releases/tag/v4.0.0
Update Node.js engine to match Next.js 16 and Vitest 4 requirements.
This package declares Node >=18.0.0 but now requires Next.js 16 (which requires Node 20.9+) and Vitest 4 (which requires Node 20+). Node 18 users can satisfy this package's engine constraint but will fail when running Next.js 16 or Vitest 4. Update to Node 20.9+ to ensure compatibility.
Proposed fix
"engines": {
- "node": ">=18.0.0"
+ "node": ">=20.9.0"
},🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/next-inspector/package.json` around lines 74 - 80, The package.json
currently allows Node >=18.0.0 which is incompatible with Next.js 16 and Vitest
4; update the engines field in package.json to require Node 20.9.0 or newer
(e.g., "node": ">=20.9.0") so consumers cannot install/run with Node 18; locate
the "engines" entry in packages/next-inspector/package.json and change its node
constraint accordingly, and update any related CI/workflow configs that
reference the old Node version if present.
| testTimeout: 5000 * 10000, | ||
| hookTimeout: 5000 * 10000, |
There was a problem hiding this comment.
Cap the Vitest timeout to a realistic value.
5000 * 10000 evaluates to 50,000,000ms (~13.9 hours), so a hung test or hook can stall CI for most of a day. If the intent was “50 seconds,” make that explicit.
🐛 Proposed fix
- testTimeout: 5000 * 10000,
- hookTimeout: 5000 * 10000,
+ testTimeout: 50_000,
+ hookTimeout: 50_000,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| testTimeout: 5000 * 10000, | |
| hookTimeout: 5000 * 10000, | |
| testTimeout: 50_000, | |
| hookTimeout: 50_000, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/next-inspector/vitest.config.ts` around lines 10 - 11, The timeouts
testTimeout and hookTimeout in vitest.config.ts are set to 5000 * 10000 (~13.9
hours); change them to realistic values (e.g., 50_000 for 50 seconds or another
reasonable ms value) so tests/hooks cannot hang for hours — replace the overly
large multiplication with an explicit millisecond constant and ensure both
testTimeout and hookTimeout use the corrected value.
Summary by CodeRabbit
Chores
Refactor