A module counts how many times its top-level code runs and five different modules import it. How many times does the body actually run, what identifies a module instance, and how can a codebase end up with two separate instances of what looks like the same module?

## One evaluation per instance ```js // counter.js let loads = 0; loads++; console.log('counter.js evaluated', loads); export const state = { hits: 0 }; ``` No matter how many modules import `counter.js`, that log appears once. During construction the engine records the module in a registry; the first time it is needed, it is fetched, parsed, linked, and evaluated, and every subsequent import of the same key reuses that record. The importers all share the same `state` object, so mutations by one are visible to all — the accidental-singleton property that module-scoped state relies on. Two consequences follow. First, top-level code is initialisation code that runs exactly once, in graph order, and never again — including on a later import of the same module. Second, if that code throws, the module is permanently marked as failed; it is not retried on the next import. ## What identifies an instance The registry key is the module's **resolved** location, not the specifier you typed. `./util.js` in one file and `../lib/util.js` in another, resolving to the same URL or file, are the same instance. Conversely, anything that changes the resolved key produces a different instance, and JavaScript makes no attempt to notice that the *contents* are identical. The host matters here in the way you'd expect but should be careful about: a browser keys its module map by URL; a server runtime keys by the resolved file URL after its own resolution rules run. Rather than asserting the fine print of a particular runtime, say the level-appropriate thing in an interview: *resolution happens first, and the resolved result is the identity*. ## How duplicates happen **Two copies in the dependency tree.** Two of your dependencies require incompatible versions of a shared package, so the installer keeps two physical copies at different paths. Both are legitimately resolved, both are evaluated, and the "singleton" inside that package now exists twice. **A specifier that resolves differently.** Appending a query string — `./m.js?v=2` — makes a distinct key against a browser's module map, and the module is fetched and evaluated again. (That is sometimes done on purpose to force re-evaluation; it is a duplicate instance either way.) **The same file reached by two paths.** Path aliasing, a symlinked local package, or an inconsistent mix of extensionless and extensioned specifiers can each yield two distinct resolved keys for one file on disk. **A separate realm.** A worker, or a separate frame, has its own registry and its own copy of everything, with no sharing of module state at all. This one is not a bug; it is the boundary working as designed, and code that assumes a shared module singleton across it is the bug. ## Symptoms and diagnosis The tells are familiar once you have seen them: a cache or connection pool that behaves as if it were empty for half the app; a plugin registry that has entries in one place and not another; a configuration object mutated at startup that some module reads as untouched; an `x instanceof Foo` check failing on an object that is visibly a `Foo`, because two copies of the class exist and identity is per-copy. To confirm, add a one-line, temporary side effect at the module's top level that logs `import.meta.url` — the module's own resolved URL, available inside any ES module. Two lines with different URLs is the whole diagnosis; two lines with the *same* URL would mean something else entirely (two realms, or two separate loads of the application). At the package-manager level, listing the installed tree shows whether a package appears at more than one path. ## Designing around it The robust answer is to reduce how much you depend on module identity. Prefer explicit wiring — create the shared object once at your entry point and pass it to the code that needs it — over relying on `import` to hand everyone the same thing. Where a package genuinely must be a singleton across a whole application, the standard mitigations are structural rather than clever: converge the dependency on one version so only one copy is installed, or declare it as a peer of the packages that share it so the top-level application owns the single copy. And notice what does *not* help: exporting a frozen object, using a class with a static instance, or a lazily-created instance behind a getter. Every one of those lives inside the module, and if the module is instantiated twice, so is it. The fix has to happen at the level that decides how the specifier resolves.