Skip to content

override isn't required in ambient contexts with noImplicitOverrideΒ #60635

Description

πŸ”Ž Search Terms

override ambient type declaration class dts noImplicitOverride

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?noImplicitOverride=true&ts=5.8.0-dev.20241128&ssl=15&ssc=2&pln=1&pc=1#code/PTAEAEDsHsEkFsAOAbAlgY1QFwPIDcBTAJyNQBMCAuULIgVwIChGL1kBDIg0N9gZz6gAQv24BvRqFAAjapDrxpxANyMAvs1YcuPDgNAARYqkJlQBAB5YCkMoJF9xkmXIVKiqjSwK8dvfQ4EAEygYl5anNz+gkakpiGW1rb2oiESUtCEJOTcsqDyiirqjEA

πŸ’» Code

// @noImplicitOverride: true

declare class Base {
  b: number;
}

declare class Derived extends Base {
  b: number; // no error
}

declare class Base2 {}

declare class Derived2 extends Base2 {
  override b: number; // error
}

πŸ™ Actual behavior

A property in a derived class in ambient context doesn't have to have override modifier with noImplicitOverride. override is still checked when present though.

πŸ™‚ Expected behavior

It feels slightly inconsistent. I couldn't find any note about this in the docs and I had to look into the source code and dig up the PR that implemented override to check if it's a bug or not.

Additional information about the issue

I believe this works like that since noImplicitOverride was introduced in #39669 in 4.3: TS playground

Activity

  1. whzx5byb commented on Nov 28, 2024

    @whzx5byb

    Seems like there was a decision:

    - Should this apply to declaration files?
      - Argument for yes: correctness for the same reason
      - Argument for no: convenience, no need to mess with declaration emitter
      - If no: Declaration emitter will need to emit `override` modifier (same way `any` works) if one was not present explicitly
      - Decision: Not enforced
    

    Originally posted by Ryan Cavanaugh (@RyanCavanaugh) in #9034

  2. typescript-bot commented on Dec 5, 2024

    @typescript-bot
    Contributor

    This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

  3. locked as resolved and limited conversation to collaborators on Oct 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Working as IntendedThe behavior described is the intended behavior; this is not a bug

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions