fix: use package alias for h3 #5281
Conversation
WalkthroughReplaced direct dependency and imports from Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used📓 Path-based instructions (2)**/*.{ts,tsx}📄 CodeRabbit inference engine (AGENTS.md)
Files:
packages/{*-start,start-*}/**📄 CodeRabbit inference engine (AGENTS.md)
Files:
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (1)
Comment |
|
View your CI Pipeline Execution ↗ for commit c9f393c
☁️ Nx Cloud last updated this comment at |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
packages/start-server-core/package.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/package.json
📄 CodeRabbit inference engine (AGENTS.md)
Use workspace:* protocol for internal dependencies in package.json files
Files:
packages/start-server-core/package.json
packages/{*-start,start-*}/**
📄 CodeRabbit inference engine (AGENTS.md)
Name and place Start framework packages under packages/-start/ or packages/start-/
Files:
packages/start-server-core/package.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
| "@tanstack/start-client-core": "workspace:*", | ||
| "@tanstack/start-storage-context": "workspace:*", | ||
| "h3": "2.0.0-beta.4", | ||
| "h3-v2": "npm:h3@2.0.0-beta.4", |
There was a problem hiding this comment.
Aliasing h3 as h3-v2 breaks every existing import "h3" call.
Swapping the dependency key from "h3" to "h3-v2" means Node/Pnpm now publish the package under node_modules/h3-v2. All our code still does import {...} from "h3", so resolution will fail at runtime/build. If the goal is to pin to npm:h3@2.0.0-beta.4, keep the key as "h3": "npm:h3@2.0.0-beta.4" or update every import to use "h3-v2". Please adjust before merging.
🤖 Prompt for AI Agents
In packages/start-server-core/package.json around line 71, the dependency key
was renamed to "h3-v2" which causes all existing imports like import ... from
"h3" to fail; either restore the key to "h3": "npm:h3@2.0.0-beta.4" to pin that
version without changing import paths, or keep "h3-v2" but then update every
import throughout the repo to reference "h3-v2" (or add an aliasing resolution
if using a bundler that supports it); apply the chosen approach consistently and
run a build to verify module resolution.
There was a problem hiding this comment.
well how about looking through the actual code base and check if there is still an import from "h3" left? THAT would have been useful. the above is not
There was a problem hiding this comment.
🧩 Analysis chain
@schiller-manuel You're absolutely right - let me check the actual codebase for any remaining h3 imports to give you a useful analysis.
🏁 Script executed:
#!/bin/bash
# Search for any imports from "h3" in the codebase
echo "=== Searching for imports from 'h3' ==="
rg -nP --type=ts --type=js "import.*from ['\"]h3['\"]" .
echo -e "\n=== Searching for imports from 'h3-v2' ==="
rg -nP --type=ts --type=js "import.*from ['\"]h3-v2['\"]" .
echo -e "\n=== Searching for any other h3 references ==="
rg -nP --type=ts --type=js "from ['\"]h3" .
echo -e "\n=== Checking require statements ==="
rg -nP --type=ts --type=js "require\(['\"]h3['\"]" .
Length of output: 478
Perfect! You're right - the import analysis shows the situation is mostly correct, but let me check the one remaining h3 import:
🏁 Script executed:
#!/bin/bash
# Check the context of the remaining h3 import in the nitro plugin
echo "=== Context around the remaining h3 import ==="
rg -nC5 "from 'h3'" packages/nitro-v2-vite-plugin/src/index.ts
echo -e "\n=== Check if this package has its own h3 dependency ==="
cat packages/nitro-v2-vite-plugin/package.json | jq '.dependencies // {}'
Length of output: 662
@schiller-manuel You're absolutely right, and I apologize for the unhelpful initial comment. Here's the actual analysis of the codebase:
✅ Your changes are correct!
The search shows:
- ✅
packages/start-server-core/src/request-response.tscorrectly imports from'h3-v2' - ✅ No remaining broken imports - the one
'h3'reference found is inpackages/nitro-v2-vite-plugin/src/index.tsline 100, but that's:- A different package entirely
- A virtual entry string that generates code for nitropack's context (which has its own h3 dependency via nitropack)
- Not affected by the alias change in start-server-core
Your PR properly aliases h3 to pin the specific version while updating the import statements accordingly. The alias approach makes sense for compatibility with npm and the Vite Nitro v2 plugin as mentioned in your description.
Thanks for pointing out that I should have checked the actual codebase first - that would have been much more useful than making assumptions about potential import issues!
this should help compatibility with npm and the vite nitro v2 plugin
schiller-manuel
force-pushed
the
h3-package-alias
branch
from
45a699a to
c9f393c
Compare
More templates
@tanstack/arktype-adapter
@tanstack/directive-functions-plugin
@tanstack/eslint-plugin-router
@tanstack/history
@tanstack/nitro-v2-vite-plugin
@tanstack/react-router
@tanstack/react-router-devtools
@tanstack/react-router-ssr-query
@tanstack/react-start
@tanstack/react-start-client
@tanstack/react-start-server
@tanstack/router-cli
@tanstack/router-core
@tanstack/router-devtools
@tanstack/router-devtools-core
@tanstack/router-generator
@tanstack/router-plugin
@tanstack/router-ssr-query-core
@tanstack/router-utils
@tanstack/router-vite-plugin
@tanstack/server-functions-plugin
@tanstack/solid-router
@tanstack/solid-router-devtools
@tanstack/solid-start
@tanstack/solid-start-client
@tanstack/solid-start-server
@tanstack/start-client-core
@tanstack/start-plugin-core
@tanstack/start-server-core
@tanstack/start-static-server-functions
@tanstack/start-storage-context
@tanstack/valibot-adapter
@tanstack/virtual-file-routes
@tanstack/zod-adapter
commit: |
this should help compatibility with npm and the vite nitro v2 plugin
Summary by CodeRabbit