fix: nextjs start error

[zh-lx]

No description provided.

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Fix Next.js start error with safe require detection

🐞 Bug fix

Walkthroughs

Description

• Fix Next.js start error by replacing unsafe global require access
• Use typeof check to safely detect require availability
• Prevent runtime errors in environments without require

Diagram

flowchart LR
  A["globalThis.require?.resolve"] -- "replaced with" --> B["typeof require check"]
  B -- "safely handles" --> C["require.resolve or null"]

Loading

File Changes

1. packages/turbopack/src/index.ts 🐞 Bug fix +1/-1

Safe require detection for webpack entry resolution

• Replaced globalThis.require?.resolve with `typeof require === 'undefined' ? null :
 require.resolve`
• Improves compatibility with environments where require is not available
• Prevents potential runtime errors during Next.js start

packages/turbopack/src/index.ts

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

1. Null passed to resolver 🐞 Bug ⚙ Maintainability

Description

TurbopackCodeInspectorPlugin now passes null for requireResolve, but resolveWebpackEntry
declares requireResolve? as an optional function, not null, which breaks the call-site contract
and can fail strict-null-checked compilation. Use undefined for the “not available” case (or widen
the type if null is truly intended).

Code

packages/turbopack/src/index.ts[48]

+    requireResolve: typeof require === 'undefined' ? null : require.resolve,

Evidence

The call site passes null when require is not present, but the function parameter is declared as
an optional function (i.e., undefined when absent). The repo root TypeScript config enables
strict, which includes strict null checks, making null incompatible with an optional function
type in strict compilation paths.

packages/turbopack/src/index.ts[15-18]
packages/turbopack/src/index.ts[47-50]
tsconfig.json[1-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`requireResolve` is typed as an optional function, but the plugin passes `null` when `require` is unavailable. This violates the function’s declared API and can break strict-null-checked compilation.

### Issue Context
At runtime, both `null` and `undefined` behave the same with the current `typeof ... === 'function'` check, but `undefined` matches the intended “optional” contract.

### Fix Focus Areas
- packages/turbopack/src/index.ts[47-50]

### Suggested change
- Replace `typeof require === 'undefined' ? null : require.resolve` with `typeof require === 'undefined' ? undefined : require.resolve` (or omit the property entirely when `require` is undefined).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Null WebpackEntry unhandled 🐞 Bug ☼ Reliability

Description

resolveWebpackEntry can return null, but TurbopackCodeInspectorPlugin uses its result
immediately in path.resolve(WebpackEntry, '..'), which will throw if that null path is hit. Add a
guard and fail closed (e.g., return {}) or throw a clear error before calling path.resolve.

Code

packages/turbopack/src/index.ts[R47-51]

  const WebpackEntry = resolveWebpackEntry({
-    requireResolve: globalThis.require?.resolve,
+    requireResolve: typeof require === 'undefined' ? null : require.resolve,
    importMetaResolve: import.meta.resolve,
  });
  const WebpackDistDir = path.resolve(WebpackEntry, '..');

Evidence

The helper explicitly returns null when neither resolver function is provided. The plugin then
uses that value as a path segment without checking, and the test suite confirms the helper’s null
behavior is expected/intentional.

packages/turbopack/src/index.ts[26-29]
packages/turbopack/src/index.ts[47-52]
test/turbopack/index.test.ts[138-141]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`TurbopackCodeInspectorPlugin` assumes `resolveWebpackEntry()` always returns a string, but `resolveWebpackEntry()` can return `null`. If that happens, `path.resolve(WebpackEntry, '..')` will throw.

### Issue Context
`resolveWebpackEntry({})` is explicitly tested to return `null`, so the plugin should defensively handle that possibility.

### Fix Focus Areas
- packages/turbopack/src/index.ts[47-52]
- packages/turbopack/src/index.ts[15-29]

### Suggested change
- After computing `WebpackEntry`, add an explicit check:
 - if `WebpackEntry == null`, return `{}` (or throw a descriptive error) instead of calling `path.resolve`.
- Optionally, consider making `resolveWebpackEntry`’s return type explicit (`string | null`) to reflect actual behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (9dab80d) to head (83abf75).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##              main      #514    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           23        23            
  Lines         2821      3689   +868     
  Branches       695       982   +287     
==========================================
+ Hits          2821      3689   +868     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.