Repository navigation
Fix Next.js turbopack ENV inlining for workspace packages and browser-only files - #1136
Merged
Merged
Conversation
The loader skipped every file outside the app dir, so ENV refs in monorepo workspace packages were never inlined for the browser. It also only treated 'use client' files as client code, so browser-only files like instrumentation-client.ts got undefined values in dev plus the server init guard. Now only node_modules and varlock's own packages are skipped, and a browser-conditioned turbopack rule marks browser-compiled files.
Contributor
|
The changes in this PR will be included in the next version bump.
|
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes in the Next.js integration's Turbopack loader eligibility, browser compilation detection, version-specific rule construction, and associated tests.
- Workspace package transforms: Source outside the app root is now transformed while
node_modules, the integration package, and resolvedvarlockpackage paths remain excluded. - Browser-targeted compilation: Browser rules flag client output without relying solely on a
use clientdirective, with aninstrumentation-client.*fallback for older Next.js versions. - Version-specific rules: Next 16+ uses disjoint
browserand non-browser conditions, Next 15.5 uses keyednodeandbrowserrules, and older versions retain the flat rule. - Regression coverage: Loader and rule tests cover browser inlining, server guard exclusion, workspace paths, dependency exclusions, versioned rule shapes, and build mode.
azure/gpt-5.6-sol ｜ 𝕏
varlock
@varlock/nextjs-integration
@varlock/native-helper-darwin
@varlock/native-helper-linux-arm64
@varlock/native-helper-linux-x64
@varlock/native-helper-win32-x64
commit: |
Its require()s resolve from the file's location, and workspace packages usually don't have @varlock/nextjs-integration installed (pnpm strict layout), so server files in packages failed with Module not found.
Contributor
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes since the prior Pullfrog review, focusing on the new handling for server files outside the Next.js project root.
- Restricted guard injection: Limited the server initialization guard to app-root files so workspace packages do not receive imports that cannot resolve under strict package layouts.
- Preserved build inlining: Kept static
ENVreplacement active for server files outside the app root while leaving browser and app-root handling unchanged. - Added regression coverage: Verified outside-root server files omit integration imports while build-time values remain inlined.
azure/gpt-5.6-sol ｜ 𝕏
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
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
ENVvalues coming through asundefinedin the browser with Turbopack, reported for a pnpm monorepo using one schema per package.Two loader bugs:
rootContext(meant to skip symlinkedvarlock/env), soENV.Xinpackages/*was never inlined, in dev or build. Now onlynode_modulesand varlock's own package dirs (resolved through symlinks) are skipped. Files outside the project root get ENV inlining only, not the server init guard: itsrequire()s resolve from the file's own location, where@varlock/nextjs-integrationusually isn't installed (pnpm strict layout), and the app's own files already run it.'use client'were treated as server files. Client detection only sniffed the directive, soinstrumentation-client.ts(and plain modules imported from client components) got no inlining in dev, plus the server init guard injected into the browser bundle. The plugin now adds a separatebrowser-conditioned turbopack rule (Next 16condition, Next 15.5 per-condition object) that flags browser compiles to the loader. Next <15.5 falls back to matchinginstrumentation-client.*by name.Rule construction moved to
turbopack-rules.tsso it can be unit tested. Webpack is unaffected (DefinePlugin already covered all files).Verified in a pnpm monorepo repro (Next 16.3.6): turbopack dev and build now inline values in both the app's
instrumentation-client.tsand a client-imported workspace package, and a server-imported workspace package (no integration dep) builds and serves; webpack build still works. Next.js v15/v16 framework tests pass.