NodeNext and Bundler Resolution
NodeNext and Bundler Resolution — the core idea
NodeNext models modern Node.js module loading and usually requires explicit .js extensions in relative ESM imports, even from .ts source files. Bundler resolution supports package exports but commonly accepts extensionless relative imports because a bundler rewrites them. Select a mode based on the actual deployment.
What you’ll learn
- Explain nodenext and bundler resolution with a concrete use case.
- Run the example and account for every line of its output.
- Recognize the difference between compile-time checking and runtime behavior.
Understand the rules and when to use them
Reading the code: This model prints the two choices; the values describe strategies but do not configure tsc. A real NodeNext project uses matching module/moduleResolution settings and ESM imports such as "./utils.js".
Keep the boundary clear: An extensionless import accepted by bundler resolution may fail in unbundled Node.js ESM at runtime.
See the idea as a flow
Run the complete TypeScript example
Save the code as nodenext-bundler-resolution.ts. The result below was captured after compiling this exact example with strict TypeScript checking and executing the emitted JavaScript in Node.js.
TypeScript code
type Mode = "nodenext" | "bundler";
const config: Record<Mode, string> = {
nodenext: "Node.js loader rules",
bundler: "Bundler loader rules"
};
console.log(config.nodenext);
console.log(config.bundler);Verified output
Node.js loader rules
Bundler loader rulesBuild: npx tsc --strict --target es2022 --module commonjs --lib es2022,dom,esnext.disposable nodenext-bundler-resolution.ts; run: node nodenext-bundler-resolution.js. The exact filename may be changed freely. When a multi-file project exists, prefer its tsconfig.json and build scripts.
Trace the example line by line
This model prints the two choices; the values describe strategies but do not configure tsc. A real NodeNext project uses matching module/moduleResolution settings and ESM imports such as "./utils.js".
The output shown above comes from the initialized values in this program. Replacing a type annotation alone does not transform a JavaScript value.
Build the real multi-file example
This separate mini-project demonstrates real imports, exports, or declarations across files. Create each file in one folder, then compile and run main.js. The example was checked separately from the single-file program.
util.ts
export const value=17;
main.ts
import {value} from "./util.js";console.log(value);
ESM setup: create package.json containing {"type":"module"}, use npx tsc --strict --target es2022 --module nodenext --moduleResolution nodenext main.ts, and run node main.js. Keep the package.json alongside the emitted JavaScript.
Verified output from the mini-project
17Avoid this common mistake
An extensionless import accepted by bundler resolution may fail in unbundled Node.js ESM at runtime.
Check both the TypeScript diagnostic and the emitted JavaScript behavior. A program can compile correctly and still need runtime validation or error handling.
Practice independently
Try importing "./util" versus "./util.js" in a NodeNext ESM example, and note which import type-checks.
Before running your change, write down the type you expect TypeScript to infer and the output you expect JavaScript to print. Then check both predictions.
Check your understanding
What to remember
NodeNext models modern Node.
Try the practice change and re-run the exact program to test your understanding.
Reaching the recap and completing the quizzes are separate milestones.