Assignment To Imported Binding

ID

javascript.no_import_assign

Severity

high

Remediation Complexity

trivial

Remediation Risk

low

Remediation Effort

low

Resource

Reliability

Language

JavaScript

Tags

modules, reliability

Description

Reports assignments whose left-hand side is a binding introduced by an import declaration. ES module imports are read-only:

  • In strict module code (the default for any file that uses import/export) the assignment throws TypeError at runtime.

  • When the assignment appears to succeed (loose contexts, re-exports), the imported module’s binding is unaffected — only the local namespace shadow changes — so callers downstream still see the original.

Both outcomes are surprising and almost always typos for a member assignment (mod.x = 1) or a refactor leftover.

Rationale

import defaultThing, { name } from "some-module";

// Bad — TypeError in strict mode; silently shadows in loose mode.
defaultThing = 1;
name = "x";

Remediation

Either work with a local rebinding or mutate the imported namespace’s properties when that is the intent:

import defaultThing, { name } from "some-module";

// Good — local rebinding, no clash with the imported binding.
let local = defaultThing;
local = 1;

// Good — mutating a property on the imported namespace is allowed.
import * as mod from "some-module";
mod.cache = new Map();

References