Modules and Bundling

import() is a syntactic form that starts loading a module at runtime and evaluates to a Promise for that module's namespace object. A static import declaration is resolved before any code in the file runs and binds the exported names directly.

A named export binds a value to a specific export name that importers must match exactly, using braces: import { parse } from './m.js'. A default export registers the value under the name "default", and the importer may bind it to any identifier it likes.

No. Top-level declarations in an ES module live in that module's own scope, so globalThis.config and globalThis.init stay undefined. In a classic script the same declarations become properties of the global object.

The dependency prints first. Import declarations are hoisted and the whole module graph is linked before anything is evaluated, so dep.js runs to completion before any statement in main.js — including a statement written above the import.

exports is a local variable that initially points at the same object as module.exports, and require() returns module.exports. Attaching properties through exports works; assigning a new object to exports only rebinds the local variable, so importers still get the original empty object.

The static import makes the library part of the initial module graph, so it is fetched and evaluated before the page code runs. Moving it into import() defers the fetch until the first click. Five clicks fetch and evaluate it once — later calls resolve from the module map.

It logs 1. An ES module import is a live, read-only binding to the exporter's own variable rather than a copy of its value, so reading count after increment() has run sees the exporter's updated value.

Module code is strict by definition, so the pragma is redundant and there is no way to opt out. Strictness is lexical, not caller-dependent: a function written inside a module stays strict wherever non-strict code later calls it.

ES module imports are static by design: an import declaration may appear only at the top level of a module, and its specifier must be a string literal. That lets the engine read the whole dependency graph out of the syntax and link it before running any code — which conditional or computed imports would make impossible.

Node's ESM loader exposes a CommonJS module's entire module.exports value as its default export, so the import binds the function. A compiler instead rewrites the import to read a default property off the required object, which does not exist unless an interop helper wraps it.

Top-level await marks the module as asynchronous: its body runs only up to the await, resumes when the awaited promise settles, and every module importing it has its own evaluation held until that finishes.

A top-level side effect is anything a module body does on evaluation that is observable outside itself: assigning to a global, mutating a built-in prototype, registering with a shared registry, or calling an opaque function. Analysis is conservative, so unprovable purity keeps the module.

JavaScript allows circular imports. Both ES modules and CommonJS register a module before running its body, so the cycle terminates instead of looping. Loading never errors by itself — trouble comes when one module reads a value the other has not produced yet.

Assigning to config fails: an imported name is a read-only binding, so the write is rejected with an error and never reaches the exporter. Setting config.debug = true works, because both modules point at the same object.

The package was written as ES modules and compiled down to CommonJS. Compilers put an ESM default export on the exports object under a default property and add an __esModule marker, so the callable value is pkg.default, not pkg.

Top-level await exists only in the ES module goal, added in ES2022. A classic script or a CommonJS file is parsed as a script, where await is not a keyword outside an async function, and CommonJS loading is synchronous so a module could not suspend anyway.

An unused named binding can be deleted because static analysis proves no code reads it. A bindings-free import asks for the module's evaluation rather than for a name, so its top-level code is the requested effect and must still run.

b.js receives a.js's partially populated exports object: done is false, and anything a.js assigns after its require call is simply absent. CommonJS caches the module object before running the body, so the back-edge require returns whatever exists at that instant — silently.

b.js evaluates first and throws ReferenceError: Cannot access 'fromA' before initialization. Linking already created the binding for a.js's const, but a.js's body has not run yet, so the binding is still in its temporal dead zone.

The exported object stored a copy of the number at the moment the module ran, so its count property has no link to the module's variable, and destructuring copies that stale value again. Expose an accessor or a getCount() function instead.

One library ends up loaded twice in a process — once from its CommonJS build, once from its ESM build — because require and import resolve the same package name to two different files. Each copy gets its own module state and its own class identities.

import.meta is a per-module object the host fills with metadata about the currently running module. In browsers and Node ESM its url property holds the module's own URL, useful for resolving sibling assets. It is module-only syntax, so a classic script rejects it at parse time.

It forwards every named export of ./utils.js under the same names, and deliberately excludes that module's default export. It also creates no local bindings, so the re-exporting file cannot use those names itself.

Consumers see the same export either way, but the from-form creates no local binding: the barrel itself cannot reference parse. The import-then-export version does bind parse in module scope, so the file can also use the value.

Top-level this in an ES module is undefined, not the global object. Library code that assigns its export onto this, or sniffs the environment through this, throws a TypeError or silently detects nothing once the file is loaded as a module.

ES modules load in three phases: construction (fetch, parse, and recursively resolve the graph), linking (create bindings and connect each import to a real export), and evaluation (run module bodies). A name that no module exports is caught during linking, so it is a load-time error with no code executed.

It is a tooling convention marking a CommonJS exports object as lowered ES module output, so its default property is a real default export. Interop helpers read it to decide whether to pass the object through or wrap it as { default: value }.

It prints a1, b, a2, main. The await in a.js suspends only that module, so the independent sibling b.js evaluates immediately; main.js runs last because it waits for both dependencies to finish.

A barrel makes every re-exported module part of the graph, so each must be parsed and, unless its top level is provably inert, evaluated. One impure module among forty is enough to pull itself in, and re-export chains amplify the cost.