feat(console): bootstrap console webapp workspace and stack decisions#476
Conversation
Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>
Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>
PR SummaryLow Risk Overview Adds
Reviewed by Cursor Bugbot for commit 09235ee. Bugbot is set up for automated code reviews on this repo. Configure here. |
WalkthroughThis PR introduces a new ChangesConsole webapp workspace and CI
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Browser
participant main.tsx
participant Router as getRouter/RootRoute
participant HomeScreen
Browser->>main.tsx: load index.html, execute script
main.tsx->>Router: create QueryClient + getRouter(queryClient)
main.tsx->>Router: mount RouterProvider in `#app`
Router->>HomeScreen: render index route via Outlet
HomeScreen-->>Browser: display console landing card
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
Reviewed by Cursor Bugbot for commit 09235ee. Configure here.
|
|
||
| [tasks."check:web"] | ||
| dir = "tsworkspace" | ||
| run = "pnpm fmt:check && pnpm lint && pnpm typecheck" |
There was a problem hiding this comment.
Mise web check incomplete
Medium Severity
The new check:web task only runs format, lint, and typecheck, while ci-web also runs build, tests, and check:primitives. Because check now depends on check:web, mise check can pass locally while the web workflow would still fail on build, test, or Radix policy violations.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 09235ee. Configure here.
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
.github/workflows/ci-web.yml (1)
21-68: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winConsider adding
timeout-minutesto the verify job.No timeout is set on the
verifyjob. A hung step (e.g., a frozenpnpm installor a turbo task that deadlocks) could consume runner minutes indefinitely. Addingtimeout-minutes: 15(or similar) is a cheap safeguard.⏱️ Suggested addition
jobs: verify: runs-on: ubuntu-latest + timeout-minutes: 15 steps:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci-web.yml around lines 21 - 68, The verify job currently has no runtime limit, so add a job-level timeout to the verify job definition to prevent hung steps from consuming runner minutes indefinitely. Update the jobs.verify configuration in the workflow to include timeout-minutes with an appropriate value, keeping the existing Checkout, Setup pnpm, Setup Node, and pnpm-based verification steps unchanged..mise.toml (1)
33-35: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
check:webomits tests and primitive-layer policy.CI (
ci-web.yml) runsfmt:check,lint,typecheck,build,test, andcheck:primitives, but the localmise check:webtask only covers the first three. Developers runningmise checklocally won't catch test failures or Radix-ban violations before pushing, which CI will then surface.Consider adding
pnpm testandpnpm check:primitivesto thecheck:webrun command for parity with CI.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.mise.toml around lines 33 - 35, The check:web task is missing the same validation that CI runs, so local checks can pass while tests or primitive-layer policy still fail. Update the run command for the check:web task in mise to include pnpm test and pnpm check:primitives alongside the existing pnpm fmt:check, pnpm lint, and pnpm typecheck steps so it matches CI parity.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci-web.yml:
- Around line 30-40: The Setup pnpm step is pinned to a ref that is not a valid
commit, so the action cannot be loaded. Update the pnpm/action-setup reference
to the actual commit for v6.0.9 in the ci-web workflow, keeping the existing
Setup Node, actions/setup-node, and node-version settings unchanged.
In `@docs/adr/0019-console-webapp-stack.md`:
- Around line 43-47: Remove the date-stamped registry status from the ADR text
in the console webapp stack document and keep only the stable ownership rule
about the `@trogonai` npm scope. Update the relevant prose around the
package-naming section so it no longer claims the organization is “unclaimed and
empty as of 2026-07-08,” and ensure the wording in this ADR remains
authoritative without transient registry state.
- Around line 121-130: Add explicit React hooks lint coverage to the linting
guidance in the ADR section for the Oxc toolchain. Update the discussion around
oxlint/oxfmt to state that hooks safety is not fully covered by default and that
either an ESLint hooks pass or direct configuration of oxlint rules like
rules-of-hooks and exhaustive-deps must be included. Reference the linting
section text so it clearly communicates that hook misuse should still be caught
by CI.
In `@tsworkspace/apps/console/package.json`:
- Around line 21-24: The TanStack Router dependencies are on mismatched patch
versions, so update the package versions in package.json to keep
`@tanstack/react-router`, `@tanstack/react-router-devtools`,
`@tanstack/router-plugin`, and `@tanstack/router-cli` on the same release line. Make
the version numbers consistent in the dependency block so the runtime, devtools,
and route generator stay in lockstep.
In `@tsworkspace/apps/console/vite.config.ts`:
- Around line 7-9: The Vite config in defineConfig is using an invalid
resolve.tsconfigPaths setting, so the app’s `@/`* imports will not be resolved.
Update the config by adding a real path-resolution solution in the plugins
array, such as vite-tsconfig-paths, or by defining resolve.alias explicitly in
the same config block. Make the change in the config that currently includes
devtools(), tailwindcss(), tanstackRouter(), and viteReact() so the import
resolution works consistently for build and tests.
---
Nitpick comments:
In @.github/workflows/ci-web.yml:
- Around line 21-68: The verify job currently has no runtime limit, so add a
job-level timeout to the verify job definition to prevent hung steps from
consuming runner minutes indefinitely. Update the jobs.verify configuration in
the workflow to include timeout-minutes with an appropriate value, keeping the
existing Checkout, Setup pnpm, Setup Node, and pnpm-based verification steps
unchanged.
In @.mise.toml:
- Around line 33-35: The check:web task is missing the same validation that CI
runs, so local checks can pass while tests or primitive-layer policy still fail.
Update the run command for the check:web task in mise to include pnpm test and
pnpm check:primitives alongside the existing pnpm fmt:check, pnpm lint, and pnpm
typecheck steps so it matches CI parity.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 34de6ddd-96bf-450e-aa53-25601755b4f7
⛔ Files ignored due to path filters (2)
tsworkspace/apps/console/public/favicon.icois excluded by!**/*.icotsworkspace/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (31)
.github/workflows/ci-web.yml.mise.tomlREADME.mddocs/adr/0018-connectrpc-gateway-for-browser-product-surfaces.mddocs/adr/0019-console-webapp-stack.mddocs/adr/index.mdtsworkspace/.gitignoretsworkspace/.npmrctsworkspace/.oxfmtrc.jsontsworkspace/apps/console/components.jsontsworkspace/apps/console/index.htmltsworkspace/apps/console/package.jsontsworkspace/apps/console/src/components/ui/button.tsxtsworkspace/apps/console/src/components/ui/card.tsxtsworkspace/apps/console/src/components/ui/input.tsxtsworkspace/apps/console/src/components/ui/label.tsxtsworkspace/apps/console/src/lib/utils.tstsworkspace/apps/console/src/main.tsxtsworkspace/apps/console/src/router.tsxtsworkspace/apps/console/src/routes/__root.tsxtsworkspace/apps/console/src/routes/index.tsxtsworkspace/apps/console/src/screens/home-screen.test.tsxtsworkspace/apps/console/src/screens/home-screen.tsxtsworkspace/apps/console/src/styles.csstsworkspace/apps/console/src/test/setup.tstsworkspace/apps/console/tsconfig.jsontsworkspace/apps/console/tsr.config.jsontsworkspace/apps/console/vite.config.tstsworkspace/package.jsontsworkspace/pnpm-workspace.yamltsworkspace/turbo.json
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@0ebf47130e4866e96fce0953f49152a61190b271 # v6.0.9 | ||
| with: | ||
| package_json_file: tsworkspace/package.json | ||
|
|
||
| - name: Setup Node | ||
| uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0 | ||
| with: | ||
| node-version: 26 | ||
| cache: pnpm | ||
| cache-dependency-path: tsworkspace/pnpm-lock.yaml |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check that the pinned action versions and Node 26 are valid/available.
# Verify action versions via GitHub API
gh api repos/actions/checkout/git/refs/tags/v7.0.0 --jq '.object.sha' 2>/dev/null || echo "checkout v7.0.0 not found"
gh api repos/actions/setup-node/git/refs/tags/v6.4.0 --jq '.object.sha' 2>/dev/null || echo "setup-node v6.4.0 not found"
gh api repos/pnpm/action-setup/git/refs/tags/v6.0.9 --jq '.object.sha' 2>/dev/null || echo "pnpm/action-setup v6.0.9 not found"Repository: TrogonStack/trogonai
Length of output: 281
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the workflow context around the referenced lines.
file=".github/workflows/ci-web.yml"
wc -l "$file"
sed -n '1,120p' "$file" | cat -n
# Resolve the three action tags to their underlying commit/type.
for repo_tag in \
"actions/checkout:v7.0.0" \
"actions/setup-node:v6.4.0" \
"pnpm/action-setup:v6.0.9"
do
repo="${repo_tag%%:*}"
tag="${repo_tag##*:}"
echo "== $repo $tag =="
gh api "repos/$repo/git/refs/tags/$tag" --jq '{type: .object.type, sha: .object.sha}'
doneRepository: TrogonStack/trogonai
Length of output: 2570
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check whether the pinned SHAs themselves correspond to real commits.
for sha in \
9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 \
48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e \
008330803749db0355799c700092d9a85fd074e9 \
0ebf47130e4866e96fce0953f49152a61190b271
do
echo "== $sha =="
gh api "repos/actions/checkout/commits/$sha" --jq '.sha' 2>/dev/null || \
gh api "repos/actions/setup-node/commits/$sha" --jq '.sha' 2>/dev/null || \
gh api "repos/pnpm/action-setup/commits/$sha" --jq '.sha' 2>/dev/null || \
echo "not found"
doneRepository: TrogonStack/trogonai
Length of output: 1523
🌐 Web query:
GitHub Actions setup-node Node 26 ubuntu-latest availability 2026
💡 Result:
As of July 8, 2026, you can use Node.js 26 in GitHub Actions workflows via the setup-node action [1][2]. The setup-node action does not require a hardcoded list of supported versions to function; it supports any version of Node.js that is available from the official Node.js distribution (nodejs.org/dist) or the actions/node-versions repository [1][2][3]. Because Node.js 26 is a valid, officially released version (with version 26.5.0 being released today) [4][5], you can specify it in your workflow configuration [1][2]. To use it, you can define the version in your workflow YAML file: - uses: actions/setup-node@v6 with: node-version: '26' Alternatively, you can specify a precise version (e.g., '26.5.0') or use semantic versioning ranges (e.g., '26.x') [1][2][3]. If you do not specify a version, the action will use the default Node.js version installed on the runner, which may vary depending on the runner image updates [1][6][3]. For consistent results, it is recommended to explicitly specify '26' or a more specific version string in the node-version input [1][6][3].
Citations:
- 1: https://github.com/actions/setup-node?tab=readme-ov-file
- 2: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md
- 3: https://github.com/actions/setup-node/blob/v6/README.md
- 4: 2026-07-08, Version 26.5.0 (Current) nodejs/node#64329
- 5: Release plan – v26.x Current nodejs/Release#1152
- 6: https://docs.github.com/en/actions/tutorials/build-and-test-code/nodejs
Pin pnpm/action-setup to the commit behind v6.0.9. 0ebf47130e4866e96fce0953f49152a61190b271 isn’t a commit ref, so this step will fail to load. The actions/checkout, actions/setup-node, and node-version: 26 entries are fine.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci-web.yml around lines 30 - 40, The Setup pnpm step is
pinned to a ref that is not a valid commit, so the action cannot be loaded.
Update the pnpm/action-setup reference to the actual commit for v6.0.9 in the
ci-web workflow, keeping the existing Setup Node, actions/setup-node, and
node-version settings unchanged.
| Package names use the `@trogonai/<name>` scope per ADR 0005, and the scope is | ||
| protected against public-registry collision deliberately. An npm scope is an | ||
| owned namespace, so the `@trogonai` organization must be registered on the | ||
| public npm registry (unclaimed and empty as of 2026-07-08) before these names | ||
| are treated as authoritative; once claimed, no third party can publish under |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Remove the date-stamped registry claim.
The (unclaimed and empty as of 2026-07-08) parenthetical will go stale immediately and makes the ADR harder to keep authoritative. Keep the ownership rule, but drop the transient registry status unless a maintained check backs it.
Suggested edit
- so the `@trogonai` organization must be registered on the public npm registry (unclaimed and empty as of 2026-07-08) before these names are treated as authoritative;
+ so the `@trogonai` organization must be registered on the public npm registry before these names are treated as authoritative;📝 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.
| Package names use the `@trogonai/<name>` scope per ADR 0005, and the scope is | |
| protected against public-registry collision deliberately. An npm scope is an | |
| owned namespace, so the `@trogonai` organization must be registered on the | |
| public npm registry (unclaimed and empty as of 2026-07-08) before these names | |
| are treated as authoritative; once claimed, no third party can publish under | |
| Package names use the `@trogonai/<name>` scope per ADR 0005, and the scope is | |
| protected against public-registry collision deliberately. An npm scope is an | |
| owned namespace, so the `@trogonai` organization must be registered on the | |
| public npm registry before these names are treated as authoritative; once claimed, no third party can publish under |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/adr/0019-console-webapp-stack.md` around lines 43 - 47, Remove the
date-stamped registry status from the ADR text in the console webapp stack
document and keep only the stable ownership rule about the `@trogonai` npm scope.
Update the relevant prose around the package-naming section so it no longer
claims the organization is “unclaimed and empty as of 2026-07-08,” and ensure
the wording in this ADR remains authoritative without transient registry state.
| ### 8. Lint and format run on the Oxc toolchain | ||
|
|
||
| Linting is oxlint and formatting is oxfmt, run workspace-wide, replacing the | ||
| ESLint + Prettier combination. One Rust toolchain covers both jobs with near | ||
| instant runs, which matches the repository's tooling posture, and oxlint's | ||
| default rule set applies without a config sprawl. Generated files | ||
| (`routeTree.gen.ts`) are excluded from formatting. Adopting ESLint later is | ||
| warranted only if a needed rule class (for example exhaustive React hooks | ||
| checks) is missing from oxlint, and that adoption is additive rather than a | ||
| replacement. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
rg -n --hidden --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**' \
'oxlint|eslint-plugin-react-hooks|react-hooks|eslint' .Repository: TrogonStack/trogonai
Length of output: 5417
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | rg '(^|/)(package.json|oxlint|eslint|tsconfig|vite|biome|oxlint.*|eslint.*|.*\.config\.(js|ts|mjs|cjs)|.*rc(\..*)?)$'
echo
echo "== search for hooks-related lint rules/config =="
rg -n --hidden --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**' \
'react-hooks|hooks.*rule|rule.*hooks|exhaustive-deps|rules-of-hooks|oxlint.*react|eslint-plugin-react-hooks|eslint-plugin-react' tsworkspace docs
echo
echo "== package manifests mentioning lint toolchain =="
sed -n '1,120p' tsworkspace/package.json
echo
sed -n '1,120p' tsworkspace/apps/console/package.json
echo
echo "== relevant ADR excerpt =="
sed -n '116,136p' docs/adr/0019-console-webapp-stack.mdRepository: TrogonStack/trogonai
Length of output: 3759
🌐 Web query:
oxlint React hooks rules exhaustive-deps rules-of-hooks documentation
💡 Result:
Oxlint provides native support for React hooks rules, including implementations that correspond to the popular eslint-plugin-react-hooks [1][2]. Key React hooks rules available in Oxlint: 1. react/rules-of-hooks: This native rule enforces that React hooks are called only at the top level and from within React components or custom hooks [3][4][5]. It was introduced in v0.3.3 [3][4]. 2. react-hooks/exhaustive-deps: This rule verifies that dependency arrays for hooks like useEffect and useMemo contain all necessary dependencies [6][7]. While Oxlint provides native support for hooks-related diagnostics, some users may configure it using the react-hooks plugin prefix in their configuration files to align with established ESLint patterns [8]. In addition to these specific rules, Oxlint also offers an experimental react/react-compiler rule [9]. This rule integrates the React Compiler's analysis to lint for violations of the Rules of React, such as conditional hook calls or state mutations during render, offering a deeper level of analysis that encompasses broader best practices [9]. Oxlint is designed to be highly compatible with existing ESLint configurations, and as of March 2026, it supports running JavaScript-based ESLint plugins natively in an alpha state [10]. This allows users to leverage existing plugin suites while benefiting from the performance of the Oxlint engine [11][10]. To enable these rules, you can add the react plugin to your configuration and specify the rules under the rules object [3][9].
Citations:
- 1: https://oxc.rs/docs/guide/usage/linter/plugins.html
- 2: https://oxc.rs/docs/guide/usage/linter/js-plugins
- 3: https://oxc.rs/docs/guide/usage/linter/rules/react/rules-of-hooks.html
- 4: https://github.com/oxc-project/oxc/blob/5b8dd681/crates/oxc_linter/src/rules/react/rules_of_hooks.rs
- 5: https://oxc.rs/docs/guide/usage/linter/rules/react/rules-of-hooks
- 6: https://github.com/ubugeeei-prod/oxlint-plugins/blob/main/docs/port-targets/eslint-plugin-react-hooks.md
- 7: https://react.dev/reference/eslint-plugin-react-hooks/lints/exhaustive-deps
- 8: linter: diff in react-hooks/exhaustive-deps vs eslint-plugin-react-hooks rule oxc-project/oxc#17765
- 9: https://oxc.rs/docs/guide/usage/linter/rules/react/react-compiler.html
- 10: https://oxc.rs/blog/2026-03-11-oxlint-js-plugins-alpha.html
- 11: https://oxc.rs/docs/guide/usage/linter
🌐 Web query:
oxlint default rules React hooks enabled by default recommended preset
💡 Result:
In Oxlint, React hooks rules (such as react/rules-of-hooks) are not enabled by default [1]. By default, Oxlint primarily enables rules categorized under correctness [1][2]. While Oxlint includes built-in support for the react plugin (which covers React hooks) [3][4], these rules must be explicitly enabled in your configuration if you wish to use them [1]. To enable React hooks rules, you can add them to your.oxlintrc.json configuration file. For example: { "rules": { "react/rules-of-hooks": "error", "react/exhaustive-deps": "warn" } } There is no single built-in recommended preset that automatically activates these rules for you [5][6]. Users looking for predefined collections of rules often rely on community-maintained presets or manually configure the specific rules required for their project [2][7].
Citations:
- 1: https://oxc.rs/docs/guide/usage/linter/plugins.html
- 2: https://oxc.rs/docs/guide/usage/linter/config.html
- 3: https://oxc.rs/docs/guide/usage/linter/config-file-reference.html
- 4: https://github.com/oxc-project/oxc/blob/5b8dd681/apps/oxlint/src-js/package/config.generated.ts
- 5: https://oxc.rs/docs/guide/usage/linter/rules.html
- 6: linter: Add recommended configuration presets oxc-project/oxc#20758
- 7: https://github.com/OGS-GmbH/oxlint-presets
Add explicit React hooks linting. Oxlint supports rules-of-hooks and exhaustive-deps, but they aren’t enabled by default; keep an ESLint hooks pass or configure those rules directly, otherwise hook misuse can slip past CI.
🧰 Tools
🪛 LanguageTool
[grammar] ~129-~129: Ensure spelling is correct
Context: ...ive React hooks checks) is missing from oxlint, and that adoption is additive rather t...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/adr/0019-console-webapp-stack.md` around lines 121 - 130, Add explicit
React hooks lint coverage to the linting guidance in the ADR section for the Oxc
toolchain. Update the discussion around oxlint/oxfmt to state that hooks safety
is not fully covered by default and that either an ESLint hooks pass or direct
configuration of oxlint rules like rules-of-hooks and exhaustive-deps must be
included. Reference the linting section text so it clearly communicates that
hook misuse should still be caught by CI.
| "@tanstack/react-router": "1.170.17", | ||
| "@tanstack/react-router-devtools": "1.167.0", | ||
| "@tanstack/react-table": "8.21.3", | ||
| "@tanstack/router-plugin": "1.168.19", |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the latest compatible versions for all TanStack router packages
npm view `@tanstack/react-router` version
npm view `@tanstack/react-router-devtools` version
npm view `@tanstack/router-plugin` version
npm view `@tanstack/router-cli` version
# Check if there's a shared version recommendation
npm view `@tanstack/react-router` peerDependenciesRepository: TrogonStack/trogonai
Length of output: 1009
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## package.json excerpt\n'
sed -n '1,80p' tsworkspace/apps/console/package.json
printf '\n## TanStack router references\n'
rg -n '"`@tanstack/`(react-router|react-router-devtools|router-plugin|router-cli)"|tanstack/router' tsworkspace -S
printf '\n## package manager lock files mentioning router packages\n'
rg -n '"`@tanstack/`(react-router|react-router-devtools|router-plugin|router-cli)"' tsworkspace -g 'package-lock.json' -g 'pnpm-lock.yaml' -g 'yarn.lock' -SRepository: TrogonStack/trogonai
Length of output: 4948
🌐 Web query:
TanStack Router installation version alignment router-plugin router-cli react-router devtools same version recommend
💡 Result:
It is highly recommended to keep all TanStack Router packages at the same version [1][2]. Because TanStack Router operates as a monorepo with tightly coupled packages, internal dependencies often rely on specific versions of the core engine, router-plugin, router-cli, and devtools to maintain compatibility [1][2]. Mismatched versions frequently lead to peer dependency warnings, build errors, or unexpected runtime behavior [3][4][5]. Specifically: - Version Alignment: Packages like @tanstack/react-router, @tanstack/router-plugin, @tanstack/router-cli, and @tanstack/react-router-devtools are developed and released in tandem [1][2]. Ensuring these match prevents issues where build-time code generation (handled by the CLI or plugin) becomes incompatible with the router runtime [3][5]. - Dependency Management: If your package manager reports dependency conflicts, use your package manager's override or resolution features (e.g., pnpm overrides, yarn resolutions) to force all TanStack Router packages to the exact same version [2][6]. - Best Practice: When updating, update all related TanStack Router dependencies simultaneously to avoid the "version skew" that causes most common configuration issues [1][2]. If you are setting up a project, using the recommended scaffolding tools or ensuring your package.json dependencies are synchronized will prevent the most common installation pitfalls [7][1].
Citations:
- 1: https://deepwiki.com/tanstack/router/1.1-package-architecture
- 2: https://deepwiki.com/tanstack/router/4.2-cli-and-build-tool-integration
- 3: Manually install with NPM has version error TanStack/router#4308
- 4: fix: pin all workspace dependencies and devDependencies TanStack/router#4771
- 5: router-cli 1.141.7 favors lazy over regular routes TanStack/router#6142
- 6: Make react router as peer dep instead of dependency TanStack/router#3001
- 7: https://tanstack.com/router/latest/docs/quick-start
Align the TanStack Router package versions. @tanstack/react-router, @tanstack/react-router-devtools, @tanstack/router-plugin, and @tanstack/router-cli should stay in lockstep; mixing patch versions can put the route generator and runtime on different internal versions.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@tsworkspace/apps/console/package.json` around lines 21 - 24, The TanStack
Router dependencies are on mismatched patch versions, so update the package
versions in package.json to keep `@tanstack/react-router`,
`@tanstack/react-router-devtools`, `@tanstack/router-plugin`, and
`@tanstack/router-cli` on the same release line. Make the version numbers
consistent in the dependency block so the runtime, devtools, and route generator
stay in lockstep.
| const config = defineConfig({ | ||
| resolve: { tsconfigPaths: true }, | ||
| plugins: [devtools(), tailwindcss(), tanstackRouter({ target: 'react', autoCodeSplitting: true }), viteReact()], |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if vite-tsconfig-paths is listed as a dependency
rg "vite-tsconfig-paths" tsworkspace/apps/console/package.json tsworkspace/package.json
# Check tsconfig for path aliases
cat tsworkspace/apps/console/tsconfig.json
# Search for any other plugin that might provide tsconfigPaths resolution
rg "tsconfigPaths" tsworkspace/ --type ts -lRepository: TrogonStack/trogonai
Length of output: 821
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the Vite config in full context
cat -n tsworkspace/apps/console/vite.config.ts
# Check whether the tsconfig-paths plugin is declared anywhere relevant
rg -n "vite-tsconfig-paths|tsconfigPaths|`@/`\\*" tsworkspace/apps/console/package.json tsworkspace/package.json tsworkspace/pnpm-workspace.yaml tsworkspace/**/package.json
# Inspect the app package dependencies/devDependencies
cat -n tsworkspace/apps/console/package.jsonRepository: TrogonStack/trogonai
Length of output: 882
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect app/package metadata and any alias-related config
cat -n tsworkspace/apps/console/package.json
printf '\n---\n'
find tsworkspace -name 'components.json' -o -name 'tsconfig.json' -o -name 'vite.config.ts' | sort | sed -n '1,120p'
printf '\n--- alias/search ---\n'
rg -n "`@/`" tsworkspace/apps/console tsworkspace -g '!**/node_modules/**' -g '!**/dist/**' -g '!**/build/**'
printf '\n--- tsconfigPaths/search ---\n'
rg -n "tsconfigPaths|vite-tsconfig-paths" tsworkspace/apps/console tsworkspace -g '!**/node_modules/**' -g '!**/dist/**' -g '!**/build/**'Repository: TrogonStack/trogonai
Length of output: 4766
Add a real path-resolution plugin or alias here
resolve.tsconfigPaths isn’t a Vite option, and this app’s @/* imports depend on it. Add vite-tsconfig-paths to the plugins array or define resolve.alias explicitly, otherwise build/test imports will fail.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@tsworkspace/apps/console/vite.config.ts` around lines 7 - 9, The Vite config
in defineConfig is using an invalid resolve.tsconfigPaths setting, so the app’s
`@/`* imports will not be resolved. Update the config by adding a real
path-resolution solution in the plugins array, such as vite-tsconfig-paths, or
by defining resolve.alias explicitly in the same config block. Make the change
in the config that currently includes devtools(), tailwindcss(),
tanstackRouter(), and viteReact() so the import resolution works consistently
for build and tests.
Code Coverage SummaryDetailsDiff against mainResults for commit: 09235ee Minimum allowed coverage is ♻️ This comment has been updated with latest results |


Related