In an ES module you write `import { config } from './settings.js'` and later `config = {};`. What happens, and how is that different from writing `config.debug = true;`?

## Two different things are being written The two lines look similar and are not related at all. - `config = {}` targets the **binding** — the name-to-slot association the import created. That is the thing ES modules make read-only. - `config.debug = true` targets the **object** the slot currently points at. Nothing about modules protects that object. Confusing the two is the single most common misunderstanding about import mutability. ## Why the reassignment is rejected When a module graph is linked, each named import becomes an indirect binding into the exporting module's environment: the importer's `config` and the exporter's `config` name the same storage slot. The spec makes those import bindings immutable, so the importing module has read access only. ```js // settings.js export let config = { debug: false }; export function replaceConfig(next) { config = next; } // the exporter may rebind ``` ```js // main.js import { config, replaceConfig } from './settings.js'; config = {}; // rejected — cannot assign to an imported binding replaceConfig({}); // fine — the write happens inside the owning module ``` Engines differ in *when* they complain — some detect the assignment while compiling the module, some raise it as the statement executes — but the outcome is identical everywhere: the write never lands, and it is never silently swallowed. Module code is always strict, and a rejected write in strict mode is an error rather than a no-op. This is also why exported values feel `const`-like from the outside even when the exporter declared them with `let`. The exporter chose `let` for itself; the importer gets read access regardless. ## Why the property write succeeds `config.debug = true` never touches the binding. It reads `config` (allowed), gets a reference to an object, and writes a property on that object. The object is shared: both modules hold references to the same one, so the mutation is visible to every importer and to the exporter, immediately and without any module machinery being involved. ```js import { config } from './settings.js'; config.debug = true; // works — plain object mutation console.log(config.debug); // true, everywhere ``` If you want to prevent that too, the exporter has to make the object itself resistant — for example by exporting a frozen object, or by exporting only a getter function and keeping the object private. Module syntax alone gives you no protection here. ## Why the language draws the line where it does Making imports immutable keeps the export graph analysable: a name's writer is always the module that declared it, so tooling and readers can find every mutation by looking in one file. If any importer could rebind an export, a value's history would be scattered across the whole program, and the guarantee that a namespace object's exports correspond to real declarations would break down. Note that the restriction is about *who writes*, not about *when*: the exporter may reassign whenever it likes, and importers see the new value on their next read, because the binding is live. ## What to do when consumers need to change the value Export a function. `replaceConfig(next)` above performs the write inside the module that owns the variable, which is legal, greppable, and works identically under any module system. A second common shape is to export a single container object and let consumers write fields on it — legal because it is property mutation, though it gives up the "one writer" property that made imports immutable in the first place. ## The trap to remember Because `config.debug = true` is legal, teams sometimes conclude imports are mutable and design around it, then get an error the first time someone reassigns an import in a refactor. Say the rule crisply in an interview: **the binding is read-only, the object is not.**