tsc-silent is a tiny tool, which helps a lot. Similarly to -nowarn in C#, it supports ‑‑suppress or ‑‑suppressConfig flags and replaces tsc when you wish to ignore certain errors in the compiler’s output. The most useful feature is the ability to ignore specific errors coming from a certain file path or file pattern.
Okay, Compiler…
With TypeScript, I often spend time fixing problems that are revealed after turning another compiler’s flag on.
When I do so, my routine is:
- turn the compiler option on (say,
--strictNullChecksin many-years-old-legacy-code) - fix TS problems
profitcommit
However, it’s quite often that the list of errors is longer than my “can fix in a day” capability. And sometimes it takes weeks to make all the necessary changes before I can finally turn on the flag in the main branch. So, this “fix TS problems” step is repeated day after day.
Of course, while you work on these errors, there is a good chance that other developers’ code, committed to the project, brings new errors because the flag is still off in the main branch. And you have to fix these too.
With tsc-silent in place, I first turn the compiler option on (ignoring errors coming from some directories) in the main branch and my daily routine changes to:
- fix a unit of “can fix in a day” problems, and exclude fixed files from the list of ignored paths
- commit and profit every day
Ignore responsibly
Even though tsc-silent helps a lot, it can be risky if you aren’t careful enough.
Error codes that are too vague
Say, for good reasons, you try to turn on --strictFunctionTypes. It will report some new errors. For example, as in the case from TypeScript@2.6 announce:
It fails with a very generic error #2322. There are many other problems reported under this code, and they will all be silently ignored. If it is the case that you turn off a similar umbrella error somewhere, you may end up in more trouble than you were before you decided to introduce --strictFunctionTypes.
Error codes change
As @RyanCavanaugh mentioned, error codes change. With every release TypeScript brings new or more specific errors, so you have to manually control TypeScript upgrades to avoid problems.
Is the flag to become standard?
There is a suggestion to ignore errors in the compiler’s output by id, where valid concerns were raised by the TypeScript team, and I concur with them.
Except for the practical reasons mentioned above, I don’t agree, that the compiler should allow private members’ access in test files. From a pragmatic point of view, I cannot trust something that forgives my errors based on whether or not the file name matches a regexp hidden in the project config. They are still errors, and I want to see these errors in IDE myself; I want to be sure that everyone sees them because I wish for these errors to get fixed.
I doubt that the flag will ever become a part of the compiler. Luckily, TypeScript is a great extendable tool, and when extended and used with caution it can even handle such non-trivial use cases.