A new typescript compiler option to indicate deprecation warnings

[AbeykoonOshan]

Hi, When I wrote following code, typescript complier didn't warn me about the deprecation warning except a strikethrough of the deprecated attribute. I would like if we can setup complier with a new option for deprecation warnings.

Playground link
https://www.typescriptlang.org/play?#code/MYewdgzgLgBAZmGBeGAKApgLhgWRAVwnQFEA3dMKASm1JAEsATZAPgG8AoGGUSWdADboAthVgp0AOggAnYMSGjKAbg4BfIA

Feature request
A new typescript compiler option to detect deprecation warnings.

Actual Behaviour
Typescript tsc command doesn't warn/fail when deprecated functions/attributes used.

Expected Behaviour
Typescript complier (tsc command) to fail/warn about deprecations.

[RyanCavanaugh]

See comments in #390 (comment)

A stable definition of "using" a deprecated method is just incredibly difficult and not something we think we can deliver in a predictable-enough manner to justify making an in-box behavior. There are too many ways you can indirect a function and it's just not clear where the right place to draw the lines is, and it seems extremely likely that different people will have strong disagreements about where it's acceptable to indirect a deprecated property into a non-deprecated position and where you can't.

[alex7kom]

Many projects use @deprecated to mark properties/methods just before removing them in the next version. An option that makes compiler pretend that deprecated entities do not exist would be very helpful.

[c-ehrlich]

While it’s true that this could never catch everything anyone ever intended to deprecate, ‘@deprecated’ is so widely used that this would be very useful even if it only looks for that.

[nsmithdev]

I see deprecations in the IDE but have so far been unable to find all of them across the entire code base.
We are using Angular and most are rxjs related but we also have some generic ones like string.substr()
It would be very nice if there was a built-in flag to show deprecation usage locations with a warnings or error.
Our usage would likely be to enable it fix the problem then turn it off

Old TsLint Rule:
https://palantir.github.io/tslint/rules/deprecation/

typescript-eslint/typescript-eslint#1223
typescript-eslint/typescript-eslint#2620

[Profesor08]

It will be great to have such option, to show warnings or errors on of deprecated code usage. It will help to avoid unexpected bugs.

For example:

class Bla {
  constructor(name) {
    this.name = name;
  }

  check() {
    console.log(name);
  }
}

new Bla("ololo").check() // something interesting

name variable is declared somewhere in lib.dom, and you can just forget to write this., and you will not get any errors, but you will get unexpected bugs.

I thinks is is very important to catch such things.

[typescript-bot]

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

[douglasg14b]

This is still an ongoing issue. It's pretty awkward that you can't mark something as deprecated, and downstream users will get a compiler error with the deprecated message.

Instead they are surprised when it's removed, with no message to help them.

Someone needs to make an anti-autoclose-bot-bot.