Closed sgtwilko closed 1 year ago
TypeScript does not have the concept of warnings, only errors. So this would require #13408 first.
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.
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. https://github.com/microsoft/TypeScript/issues/51000
Calling this a dup of #13408
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.
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
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. #51000Calling 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)
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
.
🔍 Search Terms
Deprecated suppressImplicitAnyIndexErrors Warn on usage of deprecated feature
✅ Viability Checklist
⭐ 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,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