This TypeScript configuration error occurs when you enable the noImplicitOverride compiler option without also enabling noImplicitThis. The error prevents compilation until you fix the tsconfig.json settings to ensure proper type safety for both inheritance and this context checking.
The error "'noImplicitOverride' requires 'noImplicitThis'" occurs because TypeScript's compiler options have interdependencies for ensuring comprehensive type safety. noImplicitOverride is a strict mode option that requires the override keyword when a method in a subclass intentionally overrides a method from its parent class. This helps prevent bugs when base class methods are renamed but subclass methods aren't updated accordingly. noImplicitThis is another strict mode option that raises errors when the this keyword is used without proper type annotation, preventing runtime errors where this might refer to unexpected contexts. TypeScript requires both options to be enabled together because they work in tandem: when checking override relationships, the compiler needs to understand the this context to properly validate method signatures and ensure type safety throughout the inheritance chain. Without noImplicitThis enabled, TypeScript cannot guarantee that this references in overridden methods are type-safe, potentially leading to runtime errors despite the override checking.
Open your tsconfig.json file and examine the compilerOptions section. Look for the noImplicitOverride setting:
{
"compilerOptions": {
"noImplicitOverride": true,
// ... other options
}
}If you see noImplicitOverride: true but no noImplicitThis setting, this is causing the error.
Add noImplicitThis: true to your compilerOptions:
{
"compilerOptions": {
"noImplicitOverride": true,
"noImplicitThis": true,
// ... other options
}
}This satisfies TypeScript's requirement that both options be enabled together.
If you want comprehensive type safety, consider enabling strict mode which includes both options:
{
"compilerOptions": {
"strict": true,
// ... other options
}
}The strict: true option enables noImplicitOverride, noImplicitThis, and all other strict type-checking options. This is the recommended approach for new projects.
After enabling noImplicitThis, you may see new type errors related to this usage. Fix these by:
1. Adding explicit this parameter types to functions:
function example(this: MyClass) {
// this is now properly typed
}2. Using arrow functions to preserve this context:
class MyClass {
method = () => {
// this is correctly bound to the instance
}
}3. Adding type annotations to class methods where this is used.
Run TypeScript compilation to ensure the error is resolved:
npx tsc --noEmit
# or
npm run buildThe "'noImplicitOverride' requires 'noImplicitThis'" error should no longer appear. If you still see errors, check that your tsconfig.json is being read correctly and that there are no conflicting configurations in extended config files.
If you're using build tools like webpack, vite, or esbuild, ensure they're using the updated tsconfig.json:
- For webpack: Check ts-loader or babel-loader configuration
- For vite: The tsconfig.json in project root is automatically used
- For esbuild: Pass the --tsconfig flag with your config path
Also update any CI/CD configuration files to ensure they use the correct TypeScript compiler options.
The relationship between noImplicitOverride and noImplicitThis exists because TypeScript's type system needs to understand this context to properly validate method overrides. When a subclass method overrides a parent method, TypeScript must check that the this parameter (if present) is compatible between the two signatures.
Without noImplicitThis, TypeScript allows this to have type any in methods, which means it can't guarantee type safety when checking override compatibility. Enabling both options ensures that:
1. Override relationships are explicitly marked with the override keyword
2. The this context is properly typed in all methods
3. Override compatibility includes this parameter type checking
This is particularly important for:
- Library authors maintaining public APIs
- Large codebases with complex inheritance hierarchies
- Teams adopting TypeScript gradually where explicit type safety is crucial
If you encounter performance issues with these strict options enabled, consider:
- Using incremental compilation (incremental: true)
- Isolating strict checking to specific directories
- Gradually enabling options rather than all at once
Function expression requires a return type
Function expression requires a return type
Value of type 'string | undefined' is not iterable
How to fix "Value is not iterable" in TypeScript
Type 'undefined' is not assignable to type 'string'
How to fix "Type undefined is not assignable to type string" in TypeScript
Type narrowing from typeof check produces 'never'
How to fix "Type narrowing produces never" in TypeScript
Type parameter 'T' has conflicting constraints
How to fix "Type parameter has conflicting constraints" in TypeScript