Link to the code that reproduces this issue

https://github.com/lars-hagen/turbopack-edge-runtime-bug

To Reproduce

1. Create a new Next.js project:

npx create-next-app@latest turbopack-edge-runtime-bug --typescript --app --turbopack --eslint --tailwind --src-dir --import-alias "@/*"
cd turbopack-edge-runtime-bug

2. Create a middleware file src/middleware.ts:

// Simple middleware file - its mere existence triggers the bug
export function middleware() {
}

3. Create a minimal webpack loader minimal-loader.js:

module.exports = function(content) {
  return content;
};

4. Configure Turbopack to use the loader in next.config.ts:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  turbopack: {
    rules: {
      '**/*.{jsx,tsx,js,ts,mjs,mts}': {
        loaders: [{
          loader: './minimal-loader.js',
          options: {}
        }]
      }
    }
  }
};

export default nextConfig;

5. Run the dev server:

npm run dev

Current vs. Expected behavior

Current Behavior

Turbopack throws the following error:

## Error Type
Runtime Error

## Error Message
[turbopack-node]/transforms/transforms.ts:53:10
lint TP1006 path.join(???*0*, (???*2* ? ???*5* : ???*7*)) is very dynamic
  51 | }
  52 | export const fromPath = (path: string) => {
> 53 |   return join(contextDir, sep !== '/' ? path.replaceAll('/', sep) : path)
     |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  54 | }
  55 |
  56 | // Patch process.env to track which env vars are read

- *0* process.cwd*1*()
  ⚠️  process.cwd is not specified in the environment
  ⚠️  This value might have side effects

Import trace:
  webpack_loaders:
    [turbopack-node]/transforms/transforms.ts
    [turbopack-node]/transforms/webpack-loaders.ts

Expected Behavior

Turbopack should:

1. Not analyze its own internal code for Edge Runtime compatibility
2. Or ensure its internal code is Edge Runtime compatible
3. Allow webpack loaders to work when middleware files exist in the project

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041
  Available memory (MB): 24576
  Available CPU cores: 14
Binaries:
  Node: 22.17.1
  npm: 10.9.2
  Yarn: 1.22.22
  pnpm: 10.13.1
Relevant Packages:
  next: 15.5.2 // Latest available version is detected (15.5.2).
  eslint-config-next: 15.5.2
  react: 19.1.1
  react-dom: 19.1.1
  typescript: 5.9.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

Root Cause Analysis

The issue stems from Turbopack's internal webpack loader handling code at [turbopack-node]/transforms/transforms.ts. This file uses Node.js-specific APIs:

• process.cwd() (via contextDir)
• path.join()
• path.sep

When middleware exists in a project, Turbopack's Edge Runtime analyzer performs static analysis on ALL code, including Turbopack's own internal transform code. It then detects these Node.js APIs and throws an error, even though this is Turbopack's own code, not user code.

Impact

This bug prevents developers from:

• Using any webpack loaders with Turbopack when middleware files exist
• Migrating existing webpack-based projects to Turbopack if they use middleware

Additional Context

• The bug is triggered by the mere existence of a middleware file, even with an empty function body
• This issue affects any webpack loader, not just specific ones
• The minimal reproduction uses a loader that simply returns content unchanged
• This proves the issue is in Turbopack's internal code rather than in the loaders or middleware implementation