In JavaScript, a class body is strict-mode code even inside a plain non-module script that never wrote 'use strict'. What concretely changes for code inside the class, and what tends to break when an old constructor function is rewritten as a class?

## Where the strictness comes from The language specifies that all parts of a class definition are strict-mode code. That covers more than you might assume: the constructor, every prototype and static method, getters and setters, computed key expressions, field initializers, static initialization blocks, and the heritage clause. There is no directive to turn it off — writing `'use strict'` inside is redundant, and there is no `'use sloppy'`. A class defined in the middle of a legacy script is an island of strict code inside sloppy code. ## What actually changes **Silent failures become throws.** ```js class Counter { bump() { total = (total || 0) + 1; } // ReferenceError: total is not defined } ``` In sloppy code that line would have created a global named `total`. Inside a class it throws — usually the single most valuable difference, because accidental globals are a classic source of cross-module interference. Similarly, writes that used to fail quietly now throw a `TypeError`: assigning to a frozen or non-writable property, adding a property to a non-extensible object, assigning to a getter-only accessor, or assigning to `NaN`/`undefined`. ```js const cfg = Object.freeze({ retries: 3 }); class Runner { setup() { cfg.retries = 5; } } // TypeError in strict code ``` **`this` on unbound calls is `undefined`.** A method pulled off its object and called bare gets `undefined` rather than the global object, so the failure surfaces immediately as a `TypeError` on the first property access instead of silently reading or writing globals. (The binding rules themselves are a separate topic; the strict-mode part is only that there is no substitution of the global object.) **`arguments` stops aliasing parameters.** In sloppy functions, `arguments[0]` and the first named parameter are two views of one storage; writing one changes the other. In strict code they are decoupled. Old code that normalized parameters by writing into `arguments` silently stops working. **Legacy introspection throws.** `arguments.callee`, `fn.caller` and `fn.arguments` throw `TypeError` in strict code — which kills a whole family of older recursion and stack-walking tricks. **Some things become syntax errors**, so they fail at parse time rather than at run time: duplicate parameter names, legacy octal literals (`0644` — use `0o644`), `with`, `delete x` on an unqualified identifier, and using `eval` or `arguments` as an assignment target or binding name. `eval` also no longer leaks declarations into the surrounding scope. ## Strictness is lexical, not dynamic This is the part candidates most often get wrong. Strictness is a property of where code is *written*, not of who calls it: ```js function legacy() { leaked = 1; } // sloppy: defined in sloppy code class Service { run() { legacy(); // still sloppy - creates a global, no throw const inner = () => { alsoLeaked = 1; }; // strict - written inside the class inner(); // ReferenceError } } ``` So converting a class does not retroactively harden the functions it calls, and a callback you write inside a class body is strict even when it is later invoked from sloppy code. ## What breaks when porting a constructor function to a class A rewrite from `function Widget() {}` to `class Widget {}` changes several observable things at once, and the failures land in *callers*, not in the class: - **Sloppy tricks in the old constructor now throw.** Undeclared assignments and frozen-object writes that were silently tolerated become errors on the first call. - **Callers that omitted `new`** get an immediate `TypeError`, and code that borrowed the constructor with `Widget.call(this, ...)` stops working. - **Helpers that copied the prototype** with `for...in` or `Object.assign` now copy nothing, because class methods are non-enumerable. - **`Widget.prototype = { ... }` wholesale replacement** fails: a class's `prototype` property is non-writable, so it throws in strict code and silently does nothing in sloppy code. - **Ordering.** The class must be evaluated before first use; a call that used to run above the old function declaration now hits an uninitialized binding. ## How to approach the migration Convert one constructor at a time and run the code paths that construct and consume it, since none of these failures are visible until execution reaches them. Enabling strict mode across the file *first* — or moving the file to a module, where the whole file is strict — surfaces the sloppy-mode failures separately from the class-specific ones, which makes each error far easier to attribute. Grep for the old call sites: bare `Widget(` without `new`, `.call(` with the constructor, and any prototype-copying utility.