fix(build): add @workspace/registry to transpilePackages - #6
Merged
Conversation
Vercel runtime error: ENOENT trying to open /var/task/packages/registry/src/components/button/index.tsx when serving /components/buttons. Turbopack's workspace resolution for @workspace/registry was following the source path at runtime (the same pattern that works for dev mode is not safe in serverless production where the source tree is not in the deployed artifact). Adding @workspace/registry to transpilePackages tells Next to transpile the registry source as part of the apps/web build, so the runtime references are to bundled code rather than external paths. Verified locally: typecheck passes, full production build succeeds. The pre-existing build pipeline (registry tsc + apps/web prebuild + next build) keeps working — transpilePackages does not interfere with the dist build, it just makes Next prefer the source path through its own pipeline. Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Follow-up to PR #5 (install-command on detail pages). PR #5 added "bash" to the SupportedLang type in CodeBlock but did not preload the bash grammar in apps/web/lib/shiki.ts. At runtime Shiki threw: ShikiError: Language "bash" not found, you may need to load it first on every render of a component detail page. One-line fix: add "bash" to the langs array passed to createHighlighter. Shiki lazy-loads grammars; this loads only when getHighlighter() is first called, so there's no runtime overhead beyond the one-time fetch. Co-Authored-By: Claude <noreply@anthropic.com>
martyy-code
force-pushed
the
fix/vercel-registry-source-transpile
branch
from
July 29, 2026 12:05
4b6f612 to
6da22b6
Compare
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
2 participants
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.
Problem
Vercel production runtime ENOENT when serving component pages:
The bundled apps/web output references the workspace registry source path. In dev mode this resolves correctly via the workspace symlink. In Vercel serverless, the registry source tree is not shipped as part of the deployed artifact (only the dist output is), so the runtime file open fails. The same pattern works fine for
@workspace/uibecauseuiis already intranspilePackages— Next bundles its source directly into the next output.Fix
Add
@workspace/registrytotranspilePackagesin apps/web/next.config.ts. Next now transpiles the registry source files as part of the apps/web build, so the bundled code resolves the symbol inline rather than opening an external file at runtime.const nextConfig: NextConfig = { - transpilePackages: ["@workspace/ui"], + transpilePackages: ["@workspace/ui", "@workspace/registry"], }Verified
cd apps/web && npx tsc --noEmitexits 0npm run build -w apps/websucceeds (compile, typecheck, static page generation)The pre-existing
apps/web/package.jsonbuild chain — prebuild emits sources.generated.ts and apps/web/public/r/*.json, then npm run build -w @workspace/registry emits dist, then next build — keeps working unchanged. transpilePackages does not interfere with the dist build; it just makes Next prefer the source through its own pipeline instead of falling through to a runtime file open.Out of scope
npm run build -w @workspace/registrystep fromapps/web/package.jsonsince transpilePackages now makes it redundant. Holding off on that for this PR because the existing pipeline has been working and this change is only fixing the failure mode.Generated with Claude Code