Most TypeScript inheritance bugs stem from a silent failure mode: the compiler allows you to override methods without declaring your intent. When a parent class renames a method, child classes that override it suddenly define new methods instead. The application compiles, tests pass, and production breaks. ```mermaid %% alt: Problem diagram showing silent method override failure in TypeScript class hierarchy flowchart LR A("Parent renames method") --> B("Child override becomes new method") B --> C("Compiler stays silent") C --> D("Production breaks") style D stroke:#ef4444,fill:#450a0a,color:#fca5a5 ``` TypeScript 6.0 changes this by making `--noImplicitOverride` the default compiler option. Every method that overrides a parent must now use the `override` keyword. When a parent method changes, the compiler catches broken overrides immediately. ```mermaid %% alt: Solution diagram showing override keyword preventing silent failures flowchart LR A("Parent renames method") --> B("Child marked with override") B --> C("Compiler catches mismatch") C --> D("Build fails before deploy") style D stroke:#34d399,fill:#0b3b2e,color:#d1fae5 ``` This shift forces teams to update existing class hierarchies. The migration is mechanical but requires understanding where `override` applies, where it does not, and how to phase the changes across a large codebase without breaking continuous integration. ## Key Takeaways - TypeScript 6.0 enables `--noImplicitOverride` by default, requiring the `override` keyword on all methods that override parent implementations. - The new default catches inheritance bugs at compile time that previously shipped to production when parent methods were renamed or removed. - Migration requires adding `override` to every overriding method in child classes, but abstract method implementations and interface implementations do not need the keyword. - Large codebases can adopt `noImplicitOverride` incrementally by enabling it per-directory with path-specific tsconfig files or using TypeScript's project references. - Disabling the flag is reasonable for codebases with minimal inheritance or teams that enforce override discipline through code review alone. ## How `noImplicitOverride` Catches Broken Inheritance Before Production The failure mode happens when a parent class changes and child classes fall out of sync. A method rename in the parent silently converts an override in the child into a new method declaration. The child's override no longer overrides anything. Callers invoking the method through a parent reference hit the parent's implementation, not the child's. The child's "override" becomes dead code. ```typescript // Parent class before refactoring class DataSource { fetchData(): Promise { return Promise.resolve([]); } } // Child override works as expected class ApiSource extends DataSource { fetchData(): Promise { return fetch('/api/data').then(r => r.json()); } } // Parent refactored: method renamed class DataSource { loadData(): Promise { return Promise.resolve([]); } } // Child now has a NEW method, not an override class ApiSource extends DataSource { fetchData(): Promise { return fetch('/api/data').then(r => r.json()); } } // Production breaks: callers through parent reference hit empty array const source: DataSource = new ApiSource(); const result = await source.loadData(); // returns [], not API data ``` The compiler accepts this without complaint. Tests that instantiate `ApiSource` directly still pass because they call `fetchData` explicitly. Only integration tests or production traffic that uses the parent type surface the bug. With `noImplicitOverride` enabled, the child class must mark overrides explicitly. When the parent method changes, the compiler rejects the child's override as invalid. The build fails before the code reaches any environment. ```mermaid %% alt: Flowchart showing how noImplicitOverride prevents silent override bugs flowchart TD A("Parent class method") --> B("Child class override") B --> C{"override keyword present?"} C -->|No| D("Compiler error: must add override") C -->|Yes| E{"Parent method still exists?"} E -->|No| F("Compiler error: no method to override") E -->|Yes| G("Override valid") style D stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7 style F stroke:#ef4444,fill:#450a0a,color:#fca5a5 style G stroke:#34d399,fill:#0b3b2e,color:#d1fae5 ``` This matters because production inheritance bugs are expensive. A silent override failure can corrupt data, break user workflows, or expose security holes. The five-minute refactor that renames a method becomes a multi-hour incident investigation when the compiler does not catch the downstream breakage. ## The `override` Keyword: Syntax and Migration Examples The `override` keyword appears immediately before the method name. It signals to the compiler that this method intentionally overrides a parent implementation. If no parent method matches, the compiler rejects the code. ```typescript class BaseRepository { save(entity: any): Promise { return Promise.resolve(); } } class UserRepository extends BaseRepository { override save(entity: User): Promise { // Compiler verifies BaseRepository.save exists return this.persistUser(entity); } private persistUser(user: User): Promise { // Implementation details return Promise.resolve(); } } ``` When migrating an existing codebase, the compiler identifies every method that requires `override`. Run the compiler with `--noImplicitOverride` enabled and it reports each location. Add the keyword, recompile, repeat until the errors clear. ![TypeScript compiler output showing noImplicitOverride errors](https://emzvxuokuqzdkmyrzfut.supabase.co/storage/v1/object/public/blog/posts/typescript-noimplicitoverride-default-class-inheritance/content-1.jpg) The migration is mechanical but large codebases generate hundreds of errors. Automated tools exist but require caution. A regex find-replace that adds `override` to every method breaks code where the method does not actually override anything. The compiler catches these false positives, but fixing them wastes time. Instead, compile first, collect the error locations, and apply `override` only where the compiler demands it. Getters and setters follow the same rule. If a parent defines a property with a getter, the child's getter must use `override`. The same applies to setters. If the parent has both, the child must mark both. ```typescript class BaseConfig { get timeout(): number { return 5000; } set timeout(value: number) { // validation } } class ServiceConfig extends BaseConfig { override get timeout(): number { return 10000; } override set timeout(value: number) { // custom validation } } ``` The distinction is critical because forgetting `override` on a setter while adding it to a getter creates an asymmetric definition. The compiler rejects this. Either both use `override` or neither does. ## Real-World Refactoring: Fixing Class Hierarchies in a Large Codebase A large codebase with deep inheritance hierarchies generates thousands of `noImplicitOverride` errors when the flag turns on. Fixing them all before merging any code is impractical. The migration requires a phased approach that keeps the build green while incrementally adding `override` keywords. The first phase enables the flag in a single directory. Create a tsconfig.json in that directory with `noImplicitOverride: true` and let it extend the root config. Fix the errors in that directory, commit, and move to the next. This keeps pull requests small and reduces merge conflicts. ```mermaid %% alt: Flowchart showing incremental migration strategy for noImplicitOverride flowchart LR A("Root tsconfig: flag OFF") --> B("Directory tsconfig: flag ON") B --> C("Fix errors in directory") C --> D("Commit and merge") D --> E("Next directory") E --> B style C stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px ``` The second phase uses TypeScript project references. Split the codebase into multiple projects, each with its own tsconfig. Enable `noImplicitOverride` in one project at a time. This approach works better for monorepos where directories do not map cleanly to migration boundaries. Each project can have different compiler options, and dependencies flow through explicit references. The third phase involves automated tooling. Write a script that parses the compiler output, extracts error locations, and inserts `override` at each position. Run the script, recompile, fix any false positives, and commit. This works when the hierarchy is shallow and methods rarely shadow parent methods without overriding them. Deep hierarchies or creative inheritance patterns require manual review because the script cannot distinguish intentional shadowing from accidental overrides. The practical constraint is developer velocity. If the migration blocks feature work for weeks, teams resist it. If the migration happens in parallel with normal development, merge conflicts pile up. The phased approach balances these forces by localizing changes and allowing teams to complete one directory or project before starting another. Teams that defer the migration face a compounding problem. Each new class hierarchy added without `override` keywords increases the surface area of the eventual migration. TypeScript 6.0 makes the flag default, so new projects start with it enabled. Existing projects that delay the migration accumulate technical debt that grows more expensive to fix over time. ## When `override` Saves You From Silent Bugs (And When It Gets Noisy) The `override` keyword prevents two classes of bugs: silent method shadowing and unintentional overrides. Silent shadowing happens when a parent method rename converts a child override into a new method. Unintentional overrides happen when a child adds a method that accidentally matches a parent method signature. ```mermaid %% alt: Comparison flowchart showing bug prevention vs noise from override keyword flowchart LR subgraph Safe["Without override"] A1("Parent method renamed") --> B1("Child override becomes new method") B1 --> C1("Production breaks") end subgraph Protected["With override"] A2("Parent method renamed") --> B2("Compiler error on child override") B2 --> C2("Build fails before deploy") end style C1 stroke:#ef4444,fill:#450a0a,color:#fca5a5 style C2 stroke:#34d399,fill:#0b3b2e,color:#d1fae5 ``` The noise appears in shallow hierarchies with stable parent classes. A service that extends a framework base class to override a single lifecycle hook must add `override` even though the parent method never changes. The keyword adds no value but remains mandatory. Teams see this as friction without benefit. The tradeoff depends on the depth and volatility of the hierarchy. A three-level hierarchy where parent classes change monthly justifies the overhead. A two-level hierarchy where the parent is a stable framework class does not. The flag applies uniformly, so teams with mixed patterns either accept the noise or disable the flag entirely. A concrete example: a logging framework provides a base `Logger` class with a `log` method. Services extend `Logger` to customize output formatting. The base `log` method signature has not changed in five years and will not change. Requiring `override` on every service's `log` method prevents zero bugs but adds a keyword to hundreds of files. The team gains nothing from the enforcement. Contrast this with a UI component hierarchy where base components change weekly as design requirements evolve. A `Button` component extends `BaseComponent` and overrides `render`. Design requests a refactor that renames `render` to `renderContent`. Without `override`, every `Button` subclass breaks silently. With `override`, the compiler catches every breakage immediately. The keyword justifies itself in the first refactor. The implication here is that `noImplicitOverride` is not universally beneficial. Codebases with shallow, stable hierarchies pay the cost without receiving the protection. Codebases with deep, volatile hierarchies receive protection worth the cost. Teams must evaluate their own inheritance patterns before accepting the new default. ## Abstract Classes, Interfaces, and `override`: What You Must Know Abstract classes and interfaces interact with `override` differently. An abstract class defines methods that child classes must implement. These implementations do not need `override` because they fulfill a contract rather than replace an existing implementation. An interface defines a shape that classes must match. Implementations of interface methods do not need `override` because interfaces have no implementations to override. ```typescript abstract class DataProcessor { abstract process(data: string): string; execute(data: string): string { return this.process(data); } } class JsonProcessor extends DataProcessor { // No override needed: implementing abstract method process(data: string): string { return JSON.stringify(data); } // Override required: replacing concrete method override execute(data: string): string { const result = this.process(data); console.log('Processed:', result); return result; } } ``` The distinction is critical because abstract methods are contracts, not implementations. A child class that implements an abstract method satisfies a requirement. A child class that overrides a concrete method replaces existing behavior. The compiler treats these cases differently. ```mermaid %% alt: Flowchart showing when override keyword is required vs optional flowchart TD A("Child class method") --> B{"Parent has method?"} B -->|No| C("No override needed: new method") B -->|Yes| D{"Parent method is abstract?"} D -->|Yes| E("No override needed: implementing contract") D -->|No| F{"Parent method is from interface?"} F -->|Yes| G("No override needed: implementing interface") F -->|No| H("override required") style H stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px ``` Interfaces add complexity because a class can implement multiple interfaces. If two interfaces define methods with the same signature, the class provides a single implementation that satisfies both. That implementation does not use `override` because it implements two contracts simultaneously rather than replacing a single parent method. ```typescript interface Serializable { serialize(): string; } interface Loggable { serialize(): string; } class User implements Serializable, Loggable { // No override: implements both interfaces serialize(): string { return JSON.stringify(this); } } ``` The practical consequence is that teams must distinguish between implementing contracts and overriding behavior. The compiler enforces this distinction, but developers must understand it to write correct code. A method that looks like an override might be an interface implementation. A method that looks like an interface implementation might be an override if the parent class also defines it. ![Diagram showing abstract class and interface method resolution](https://emzvxuokuqzdkmyrzfut.supabase.co/storage/v1/object/public/blog/posts/typescript-noimplicitoverride-default-class-inheritance/content-2.jpg) The edge case appears when a child class extends a parent that implements an interface. The child overrides a method that the parent defined to satisfy the interface. The child must use `override` because it replaces the parent's implementation, even though that implementation exists only to satisfy an interface contract. ```typescript interface Repository { save(entity: any): Promise; } class BaseRepository implements Repository { save(entity: any): Promise { return Promise.resolve(); } } class UserRepository extends BaseRepository { // Override required: replacing parent's interface implementation override save(entity: User): Promise { return this.persistUser(entity); } private persistUser(user: User): Promise { return Promise.resolve(); } } ``` This matters because the compiler does not care why the parent method exists. If the parent defines it, the child must use `override` to replace it. The interface is irrelevant to the override check. ## Migration Strategy: Enabling `noImplicitOverride` Incrementally Without Breaking CI Incremental migration prevents the all-or-nothing problem where enabling the flag breaks thousands of files at once. The strategy depends on the codebase structure. Monorepos with independent packages benefit from per-package migration. Large monoliths with tangled dependencies require directory-level migration or project references. The directory-level approach creates a tsconfig.json in each directory that needs isolation. The directory config extends the root config and overrides only `noImplicitOverride`. Files in that directory compile with the flag enabled while the rest of the codebase remains unchanged. ```mermaid %% alt: Flowchart showing directory-level migration workflow flowchart LR A("Choose directory") --> B("Create directory tsconfig") B --> C("Enable noImplicitOverride") C --> D("Run compiler in directory") D --> E{"Errors present?"} E -->|Yes| F("Fix override keywords") F --> D E -->|No| G("Commit and merge") style F stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px ``` The project references approach splits the codebase into multiple TypeScript projects. Each project has its own tsconfig and declares dependencies on other projects. Enable `noImplicitOverride` in one project, fix the errors, and move to the next. This works better than directory-level migration when files in different directories form logical units that should migrate together. The gotcha is that project references require explicit dependency declarations. A project cannot import from another project unless the dependency appears in the first project's `references` array. Setting up references for the first time takes hours in a large codebase. Once configured, incremental migration becomes straightforward, but the upfront cost is significant. The alternative is a feature flag approach where a custom build script parses the compiler output and allows a configurable number of errors. Set the threshold to the current error count, enable `noImplicitOverride` globally, and gradually reduce the threshold as the team fixes errors. This keeps the build green while making progress visible. The downside is that new errors can slip in if the threshold is too loose. Teams that use continuous integration must ensure the migration does not block deployments. If enabling `noImplicitOverride` in a directory causes the build to fail, that failure must not prevent merging unrelated changes. The solution is to isolate the migrating directory's build from the main CI pipeline until migration completes. Use a separate CI job that runs only on changes to that directory, and merge only when that job passes. The practical constraint is team coordination. If five developers work on the same directory and each adds `override` keywords independently, merge conflicts multiply. Assign directory migration to a single developer or pair, complete it in one pull request, and merge before starting another directory. This serializes the work but eliminates conflicts. The timeline for full migration depends on codebase size and team capacity. A 100,000-line codebase with 50 class hierarchies might take two weeks with dedicated resources. A 500,000-line codebase with 200 hierarchies might take two months. Deferring the migration is an option, but TypeScript 6.0 makes `noImplicitOverride` default for new projects. Existing projects that never enable it diverge from the ecosystem standard. ## Frequently Asked Questions ### What happens if I add `override` to a method that does not override anything? The compiler rejects the code with an error stating that no parent method exists to override. This prevents false overrides and ensures the keyword only appears where it has meaning. ### Can I use `override` with static methods? Yes. Static methods follow the same rules as instance methods. If a static method in a child class overrides a static method in the parent, the child must use `override`. ### Does `override` work with private methods? No. Private methods are not part of the inheritance chain because child classes cannot access them. The compiler rejects `override` on private methods. ### What if my codebase uses mixins or multiple inheritance patterns? TypeScript does not support true multiple inheritance, but mixin patterns combine multiple classes. If a mixin method overrides a method from the base class, use `override`. If the mixin defines a new method, do not use `override`. ### Should I enable `noImplicitOverride` if my codebase has minimal class-based code? No. If your codebase uses functions and modules instead of classes, `noImplicitOverride` adds no value. Leave it disabled or accept the default in TypeScript 6.0 and ignore the few class hierarchies that exist. ## Should You Disable `noImplicitOverride`? When the New Default Does Not Fit The new default fits most codebases, but not all. Teams with shallow hierarchies, stable parent classes, or minimal inheritance see little benefit from mandatory `override` keywords. The cost of adding keywords to hundreds of methods outweighs the protection against bugs that rarely occur. Disabling the flag is reasonable when the codebase follows patterns that make inheritance bugs unlikely. A codebase that uses composition over inheritance has few parent-child relationships, so override bugs are rare. A codebase where parent classes are external framework code that never changes has no risk of silent method renames. The tradeoff is that disabling the flag opts out of ecosystem alignment. TypeScript 6.0 enables `noImplicitOverride` by default, so new projects and libraries use it. Disabling it in your codebase creates a divergence that future contributors must understand. If a developer moves from a project with the flag enabled to yours with it disabled, they expect `override` to be mandatory and may be confused when it is not. For teams using advanced TypeScript features like conditional types, mapped types, or complex generics, check out [10 TypeScript Utility Types for Bulletproof Code](/posts/10-typescript-utility-types-bulletproof-code) to see how type-level programming complements runtime inheritance patterns. For codebases considering AI-assisted refactoring tools to automate the `override` migration, [AI-Powered TypeScript Refactoring Workflows](/posts/ai-powered-typescript-refactoring-workflows) covers the practical constraints and success patterns. And for context on how modern tooling handles large-scale migrations, [2 Million Token Context Windows in Real Web Apps](/posts/2-million-token-context-windows-real-web-apps) explores the infrastructure challenges that parallel TypeScript's own compilation performance work. The decision to disable depends on how much inheritance your codebase uses and how volatile those hierarchies are. If parent classes change rarely and hierarchies stay shallow, disabling the flag removes noise without increasing risk. If parent classes change often and hierarchies run deep, the flag prevents expensive production bugs. Evaluate your patterns, measure the error count when the flag is enabled, and decide whether the protection justifies the migration cost. That covers the essential patterns for navigating TypeScript 6.0's `noImplicitOverride` default. Apply these migration strategies in your codebase and the inheritance bugs that once slipped into production will fail at compile time instead. The upfront cost of adding `override` keywords pays for itself the first time a parent class refactor catches a broken child class before deployment.

Posts tagged “class inheritance”

TypeScript 6.0 `--noImplicitOverride` Is Now Default: What Your Class Hierarchies Must Fix