the biggest problem I see with this proposal: comment attachment is no longer supported by eslint.

without comment attachment support, we would have to implement our own logic to attach jsdoc comments to the methods, as well as our own logic to parse jsdoc comments.

that being said, a decorator version is pretty simple to implement.

@bradzacher ESLint still attempts to attach comments to nodes although the API might be different than how esprima/espree used to do it. ESLint stopped supporting JSDoc specifically, but it should be possible to get the comments themselves and check for JSDoc (just check that the first character in the comment value is *, representing /**). Am I missing something?

@bradzacher one problem with the decorator solution was that the rule became sensitive of the order of the declaration inside the same file. It's possible that the rule's algorithm had a bug. Nevertheless that was why we opted for the JSDoc option in our project. Plus AFAIK decorators are still experimental and not every project uses them.

If detecting overrides is not an issue I don't think adding a comment would be harder.

@mzyil - it's relatively straightforward to check overrides though, as it's a clear algorithm.

Decorators have first-class support in the parser, but comment attachment does not. However if it's supported by in eslint (like @platinumazure says it is), then it shouldn't be too hard?

@platinumazure - is comment attachment provided by the underlying parser or by eslint itself? If it's the former - we haven't added support for it afaik.

Probably we can use sourceCode.getCommentsBefore(nodeOrToken) API.

@bradzacher ESLint does it and it should work, assuming the parser's nodes, tokens, and comments (or maybe just nodes and comments) have proper location information. I think it uses range but I'm not 100% sure.

As @mysticatea says, sourceCode.getCommentsBefore(nodeOrToken) should get you very close to what you need. You'll just need to filter the results by whether or not they are JSDoc comments (i.e., start with /** slash value starts with *).

awesome. I didn't realise it was that simple.
we could definitely consider supporting comments then!

(just spitballing so we're covering out bases)

If comments are that simple I'd rather support comments and not decorators considering that the decorator isn't (and can't be) provided by us - it'd rely on the user implementing (or importing a 3rd party implementation).
An @overrides decorator would be a noop (i.e. does nothing at runtime), which creates a useless runtime artefact. Considering we're about promoting best practices, it feels like it'd be the wrong thing for us to endorse?

I just found https://github.com/bet365/override-linting-rule as a 3rd party that supports decorators.

Is this something that can be imported as a @typescript-eslint/ rule?

unfortunately not. that is a tslint plugin which does not interop with eslint.

Have there been any progress on this? Is it accepted o rejected?

This is a community run project.
It's waiting for someone from the community to work on it.
So far, nobody has found it hi-pri enough to pick up.

If you want to have a go at it, feel free to raise a pr!

Thank you @bradzacher for the quick answer. Sadly I've never worked with the internals of tslint or eslint, I don't feel prepared to send a PR. Is there any other way to support the project and a feature (like this) in particular?

Not hugely, no. This pr has few reactions, so it's pretty low in the priority queue for the maintainers.

For now the only way it will be implemented any time soon is via a community contributor.

This pr has few reactions

I came here from the "override keyword discussion" for TypeScript.
I think there is a huge demand for this, but it does not show in this ESLint thread. However, an ESLint rule would be a good alternative to a native language feature.

Please re-consider implementing this rule, and when you do, also consider the amount of feedback from the TypeScript issue.

There's nothing to reconsider.
It just needs someone to build it.

See prior comment about this being a community maintained project. That means there's no team being paid to work and build features out on this project - it relies on the support from the open source community to volunteer their time to contribute fixed and enhancements.

The volunteer maintainers spend most of their time reviewing issues and PRs.

If someone from the community wants to tackle it, happy to accept a PR!!! That would be the best way to move this forward and get a rule built.

Note that there is microsoft/TypeScript#39669

This will be released with TS4.3
https://github.com/microsoft/TypeScript-wiki/blob/cf2951bcd15733844aed53b31020ab2fe50c15ed/Roadmap.md#43-may-2021

There will be a new flag (noImplicitOverride) and a new keyword (override)