Skip to content

fix: use package alias for h3 #5281

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
schiller-manuel merged 1 commit into from
Sep 28, 2025
Merged

fix: use package alias for h3 #5281

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion packages/start-server-core/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@
"@tanstack/router-core": "workspace:*",
"@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",
Copy link
Contributor

@coderabbitai coderabbitai bot Sep 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

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.

Copy link
Contributor Author

@schiller-manuel schiller-manuel Sep 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@coderabbitai coderabbitai bot Sep 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 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.ts correctly imports from 'h3-v2'
  • ✅ No remaining broken imports - the one 'h3' reference found is in packages/nitro-v2-vite-plugin/src/index.ts line 100, but that's:
    1. A different package entirely
    2. A virtual entry string that generates code for nitropack's context (which has its own h3 dependency via nitropack)
    3. 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!

"seroval": "^1.3.2",
"tiny-invariant": "^1.3.3"
},
Expand Down
2 changes: 1 addition & 1 deletion packages/start-server-core/src/request-response.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ import {
unsealSession as h3_unsealSession,
updateSession as h3_updateSession,
useSession as h3_useSession,
} from 'h3'
} from 'h3-v2'
import type {
RequestHeaderMap,
RequestHeaderName,
Expand Down
6 changes: 3 additions & 3 deletions pnpm-lock.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading