Option to show warning for deprecated options.

[sgtwilko]

🔍 Search Terms

Deprecated
suppressImplicitAnyIndexErrors
Warn on usage of deprecated feature

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

For features that are being Deprecated, such as suppressImplicitAnyIndexErrors can we have an option to have warnings shown.

We have an old project which had this option enabled (nobody knows why!), but there's a lot of places that error with this option removed.
I'd like to be able to see where all the non-compliant code is so we can progressively fix the issues before removing the suppressImplicitAnyIndexErrors.

It would be handy to either have:

• emitWarningsForDeprecatedFeatures setting,
• the ability to set the error/warning level in the tsconfig file, e.g.,

   "suppressImplicitAnyIndexErrors": "warning",

With either of these options set then I would want to see the warning in VSCode or when compiling.

📃 Motivating Example

Deprecated features and settings such as suppressImplicitAnyIndexErrors can have a significant impact on large projects due to the amount of rework required to satisfy the change in functionality.

With this change developers will be able to be warned about non-compliant code without it failing the build.
This allows code to be progressively updated to be compliant over the lifetime of the deprecation without having to embark on a "big-bang" conversion project.

This will allow the easier adoption of newer version of Typescript, with developers not feeling unable to upgrade due to the amount of work involed.

💻 Use Cases

1. I want to be able to upgrade to later version of typescript with the minimum of effort
2. The current system is either on or off, either failing or working.
   We cannot just turn the option off as it introduces hundreds of errors, breaking our builds.
   We can't easily see where the errors are, this makes it hard to track and mange.
   In a previously situation we've used eslint and set a rule to "Warn" and then issues can be tracked, developers see them in VSCode and progressively fix them.
3. Currently we are not planning on upgrading typescript past 5.5 unless forced to do so.

[MartinJohns]

TypeScript does not have the concept of warnings, only errors. So this would require #13408 first.

[fatcerberus]

IIRC this is all intentional - the official line is that options are deprecated in a x.0 release (5.0 in this case), but don’t start to be warnings/errors until x.5, and then are completely removed in (x+1).0.

[andrewbranch]

The deprecations happen in x.0 which are errors; the implementation is removed in x.5 but it is not an error to include the flags (alongside ignoreDeprecations, I assume?); in the next major it becomes an unrecognized flag which always errors. #51000

Calling this a dup of #13408

[andrewbranch]

I would suggest setting up another tsconfig for use in the editor, or some CI process, which unsets the deprecated flags. That way you can have builds that ignore the deprecation errors and keep using the deprecated flags when you need the build to succeed, but also have another process by which you can see the errors you need to fix in order to move past TS 5.5. It’s not perfect but with a little fiddling you can get something that works.

One time I was on a team that was trying to move a big codebase onto strictNullChecks. We set up a separate tsconfig that enabled strictNullChecks, ran it on everything in CI, and output which files failed to a test reporter so we could see percentage of files passing. (Azure DevOps also showed us this number of time, which was cool.) This was a job that always succeeded / didn’t block builds. We also had a tsconfig with a list of files that had already passed under strictNullChecks, and this was a required job, so we wouldn't regress on files that had already been fixed.

[typescript-bot]

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

[sgtwilko]

The deprecations happen in x.0 which are errors; the implementation is removed in x.5 but it is not an error to include the flags (alongside ignoreDeprecations, I assume?); in the next major it becomes an unrecognized flag which always errors. #51000

Calling this a dup of #13408

Hiya @andrewbranch,

I don't think this is a duplicate of #13408, although I would agree that it may need #13408.

For my use case this isn't about configuring individual things as warnings, it's about finding places that will not compile when the upcoming deprecations are deprecated.

I only suggested being able to configure separately as one approach to solve the issue.

I've tried a second tsconfig file, but for some reason (at least in createReactApp) we don't see a list all the places listed on the command line.
Having this used during development does show in VScode, but also shows a full screen error message in the browser on every hotreload.

As it's not showing in the command line we can't get them out in a pipeline, and the full screen error is too disruptive to have in during development.

Happy to be told I've missed something in the config, or that there's an ESLint rule (although I've turned all unsafe rules on and these issues don't get flagged)

[andrewbranch]

If you can get the errors to show up in VS Code, you can get them to show on the command line with tsc. I’m not sure what create-react-app is doing, but it sounds like you should leave it out of this secondary process and just deal with tsc.