Glossary / Static imports

Static imports

Static imports are top-level import declarations whose module specifiers and imported names are syntactically visible before the importing module executes. They establish the module graph for linking, enable live bindings, and allow hosts and build tools to analyze dependencies for loading, validation, and optimization.

Forms and semantics

import defaultValue, { named as local } from './module.js';
import * as namespace from './module.js';
import './register-polyfills.js'; // side-effect import

Imports are only permitted at module top level, not inside conditionals or functions. The binding is read-only in the importer and reflects the exporter's live binding. Import declarations are hoisted in the module's linking model, but this does not mean imported module code can be used before its dependencies are initialized; cycles can expose temporal-dead-zone errors.

A static import is not a guarantee of eager network transfer in every host: browser module scripts fetch the static graph, while bundlers may split or transform output. The declaration does make the dependency part of the static module graph. Specifier resolution is host-specific, and browser/Node ESM often require explicit relative file extensions.

Ordering and side effects

Dependencies are evaluated before the importing module body according to module graph rules. Import declarations' textual position does not serve as an imperative load-order mechanism among siblings. A bare side-effect import intentionally relies on initialization such as custom element registration or polyfills; such side effects complicate tree shaking and testing. Prefer explicit exports and initialization functions when practical.

Engineering guidance

Use static imports for stable dependencies and values needed by the module. Keep side effects narrow and documented, avoid import cycles where possible, and do not treat import declaration order as a sequencing API. For conditional or user-triggered loading, use dynamic import().

Interview questions

  1. Can static imports appear inside if? No; they are module-level declarations.
  2. Are imported bindings mutable by the importer? No, they are read-only live bindings.
  3. Does source order define dependency evaluation order? Not generally; module graph linking/evaluation rules govern it.
  4. What does import './setup.js' do? Loads and evaluates a module for its side effects without importing a binding.
  5. When choose dynamic import instead? When loading should be conditional, deferred, or initiated by runtime action.

References