fix(eve): resolve parent package tsconfig path aliases in dev runtime snapshots - #1289
Open
Mohith26 wants to merge 2 commits into
Open
fix(eve): resolve parent package tsconfig path aliases in dev runtime snapshots#1289Mohith26 wants to merge 2 commits into
Mohith26 wants to merge 2 commits into
Conversation
… snapshots A withEve agent whose root is a bare directory inside a Next.js app (no package.json/tsconfig.json of its own) bundles fine in production because authored-module bundling walks up to the owning package and passes its tsconfig path aliases to rolldown. Dev runtime snapshots broke that in two ways: the snapshot plan only scanned the app root itself for tsconfigs, so the owning package's tsconfig and alias-target sources were never copied, and the copy step synthesized a package.json at the snapshot agent root, moving the package boundary below the owning package so the parent tsconfig stayed invisible to the bundler. Mirror the dependency-declaration walk-up (vercel#1151) for tsconfig discovery: resolve tsconfigs from the nearest owning package as well, copy that package into the snapshot when its tsconfig declares path aliases, and only generate a synthetic runtime package.json when no owning package.json exists at or above the runtime app root inside the snapshot. Fixes vercel#1242
…snapshots Regression coverage for vercel#1242: a bare withEve agent directory whose imports use the parent Next.js package's tsconfig path aliases must keep resolving from dev runtime snapshots. One test asserts the snapshot carries the owning package's tsconfig, alias-target sources, and package boundary (no synthetic package.json below it) and that the authored module loader resolves the alias from the snapshot; the second reproduces the issue end-to-end by hydrating a materialized dev generation whose agent module imports parent application code through an alias.
Contributor
|
@Mohith26 is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| const runtimePackageJsonPath = join(plan.runtimeAppRoot, "package.json"); | ||
|
|
||
| if (existsSync(runtimePackageJsonPath)) { | ||
| // A synthetic package.json below an owning package that made it into the |
Contributor
There was a problem hiding this comment.
Bare-agent dev-runtime snapshots move the package boundary from the owning package to the workspace root when the owning package's tsconfig has no path aliases, diverging from production module resolution.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1242, reported by @pedro757.
A withEve agent whose root is a bare directory inside a Next.js app (no package.json or tsconfig.json of its own) bundles fine in production, because authored-module bundling walks up to the owning package and passes its tsconfig path aliases to rolldown. Dev runtime snapshots broke that in two ways: the snapshot plan only scanned the agent root itself for tsconfigs, so the owning package's tsconfig and alias-target sources were never copied, and the copy step synthesized a package.json at the snapshot agent root, which moved the package boundary below the owning package and hid the parent tsconfig from the bundler.
Fix: resolve tsconfigs and alias-target roots from the owning package (helpers extracted into dev-runtime-source-snapshot-tsconfig-paths.ts), and stop synthesizing a package boundary below it.
The 22 dev-runtime artifact integration tests pass locally, including two new ones: one asserts the snapshot carries the owning package's tsconfig, alias targets, and package boundary, and one reproduces the issue end to end by hydrating a materialized dev generation whose agent module imports parent app code through an alias. Both fail without the fix.