Provide an option to ignore TypeScript compiler errors

[earshinov]

Bug Report or Feature Request

- [ ] bug report
- [x] feature request

Command

- [ ] new
- [x] build
- [x] serve
- [x] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Versions

$ ng --version
Angular CLI: 1.7.4
Node: 8.11.1
OS: win32 x64
Angular: 5.2.11

$ npm --version
5.6.0

Windows 10.

Desired functionality

angular-cli commands like build and serve should be able to work in presence of TypeScript errors.

Most of TypeScript errors are actually warnings in the sense that they do not prevent JavaScript code to be emitted. As far as I understand, nothing prevents angular-cli to work normally as long as it receives JavaScript code and metadata (like descriptors metadata) from the TypeScript compiler, even if the compilation produces some errors.

Currently, it seems that angular-cli bails out on any TypeScript error.

Let me explain our case. We have a fairly large Angular project. To improve type checking, we would like to switch to strict: true in tsconfig.json and gradually combat the problems in the existing code TypeScript will report. At the same time, our team will immediately start to benefit from strict: true when writing new code due to the fact that more potential issues will be highlighted by our IDEs. Unfortunately, we cannot use this approach because ng serve or ng build will no longer work, i.e. our development process will be broken until we fix all the problems (which is not going to happen in the foreseeable future).

By the way, TypeScript compiler itself since quite a while ago supports the noEmitOnError option (https://www.typescriptlang.org/docs/handbook/compiler-options.html). In my opinion, in the perfect world angular-cli would rely on that. However, I understand that it hardly going to happen due to backward compatibility considerations.

[alexeagle]

You'll also have red in your editor. I think ignoring the errors is the wrong approach.

What we do at Google for this is to use or build automated fixers for the various --strict flags in TypeScript, and enable them one at a time. We never ignore compiler errors, and have to roll out the flag to the entire Google codebase at once, so we've gotten pretty good at it. In many cases, the fixer just adds an :any with a comment - this disables type-checking which is pretty much what you're asking for. We use an alias like AnyDuringTsStrictXXMigration so we can find and fix these after the flag flip.

I think we should write up a blog post about how we do this for our giant monorepo. It's not Angular-specific of course, the whole TS ecosystem needs a way to enable options (starting with --noImplicitAny in most cases) without having to fix all occurrences in the same change.

[earshinov]

@alexeagle , I wonder if you could share the code for your automated fixers?

[filipesilva]

This isn't a feature we're looking at adding at the moment, for the reasons outlined in the comment above.

I recently saw a similar post to what Alex was proposing to make, but for ionic updated: https://blog.ionicframework.com/guest-post-ionic-4-0-migration-using-tslint-fixers/. There is also a repository for rxjs fixers that follows the same idea: https://github.com/ReactiveX/rxjs-tslint.

[bgmort]

You'll also have red in your editor. I think ignoring the errors is the wrong approach.

@alexeagle, I appreciate what you're saying, but I think that being able to see the errors, be aware of them and address them incrementally is a better approach than to have to use loose compiler settings that mask those errors, or to have a bot attach :any to everything.

I just started working on a typescript project that, to date, has not been using --noimplicitany, and has not taken full advantage of typings. I would like to do the same as @earshinov, except just turning on --noimplicitany first, and let the team fix the typings as they work with them, but the build bailing on any type errors is a deterrent to that. Please consider having this be an option.

the whole TS ecosystem needs a way to enable options (starting with --noImplicitAny in most cases) without having to fix all occurrences in the same change.

It already does; it is --noEmitOnError, and the default behavior is to emit.

[nxpatterns]

In a very big project (with about 300 developers) you have to be able to ignore errors of modules, that will be lazy loaded somehow someday. Maybe this part of work has nothing to do with your work. It is terrible that you cannot start your project until they remove their conflicts (e.g. because of API-changes, somewhere, somehow). Did you ever think about this use-case?

Angular is a great project, but to my mind: I find it a pity that Silva constantly closes important open issues. (Excuse me, Silva).

That is an essential functionality to suppress certain errors. We have already discussed that so many times also in the typescript-project. (microsoft/TypeScript#9448 (comment))

Thank you!

EDIT My workaround currently looks like this: I make myself unpopular by setting @ts-ignore flags in the source code of colleagues sitting at a far corner somewhere in the company.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}