How do I get Angular to ignore typescript 'errors'

[Neutrino-Sunset]

I'm adding functionality to a large and complex Angular 11 application. I have ng build watch running and typically making large changes, testing them, and then iterating.

The biggest waste of my time at the moment is waiting for Angular to build a set of changes, go to test it, finding it's not working, then finding it's not working because the browser bundles haven't been updated and the code is stale because Typescript is pissed because there is an unused variable somewhere in the codebase.

Given the scale of the changes I'm making, time spent polishing the code to conform to every single Typescript rule ever invented, after every single change I make, when my current changes are still highly speculative and liable to change repeatedly just totally kills any productivity. Hunting down and 'fixing' the half dozen Typescript 'errors' that might occur just because I've commented out a line of code can be 10 minutes of my time that could be far better spend continuing with my work.

I would like either the IDE (VsCode) or the compiler to continue to make me aware of any Typescript issues so that I can use intelligence (that the tooling does not possess) to determine which errors to fix and when, but I do not want my builds continually failing for spurious stylistic issues.

Someone please tell me this is possible and how to achieve it.

P.S. There is absolutely no point whatsoever suggesting to people to seek answers to questions on StackOverflow. That site has been a total waste of time for years now.
https://stackoverflow.com/questions/66012370/how-do-i-get-angular-to-ignore-typescript-errors

[eneajaho]

Hi,
You can disable typescript strict checking in tsconfig.json by setting strict: false;
Maybe the project has other stricter rules, for example:

 "angularCompilerOptions": {
    "fullTemplateTypeCheck": true,
    "strictInjectionParameters": true
  }

or

  "forceConsistentCasingInFileNames": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,

You can set them all to false, and the typescript won't scream at you.

PS: I don't suggest disabling them. :)

[petebacondarwin]

Transferring to the CLI project which is responsible for running these builds.

These errors are driven by configuration in the tsconfig.json file(s).

My suggestion is that you can create a specific configuration in the angular.json that points to a specific tsconfig.json that has a these TypeScript strict flags turned off. Then when you run ng serve (or whatever) you can choose this configuration via the --config=... flag.

[Neutrino-Sunset]

Disabling the errors in the tsconfig.json prevents them from even being reported though. Ideally I would like the errors to continue to be reported, but for them not to needlessly break the build.

Is there no option to even have them reported as warnings? Every compiler I've ever used before had a mechanism by which you could control the severity with which warnings would be treated as errors and prevent the build from succeeding, but with Typescript it seems to be all or nothing, either anything that's reported breaks the build, or you disable it and get no reporting of issues whatsoever.

[alan-agius4]

Hi @Neutrino-Sunset,

As suggested above and in StackOverflow. You can specify a set of looser TypeScript options if you don't want to have errors for unused parameters and unused locals while in watch mode.

As per TypeScript handbook these two options will issue an error and hence failing the build is the correct behaviour, and there isn't a way to change this to become warnings.

TypeScript and Webpack do allow emitting of code when an error occurs, using the noEmitOnErrors. You can extend the Angular CLI using 3rd party builder such as https://github.com/manfredsteyer/ngx-build-plus to allow emitting of code when an error occurs.

[Neutrino-Sunset]

It seems like we just need to set optimization.emitOnErrors for webpack. I've tried ng add ngx-build-plus and it fails with error expected node projects/ourapp/architect/serve in angular.json. It adds the package in package.json but makes no other change.

No idea what that error means. This project has been upgraded repeatedly since Angular 4 so presumably something is not in the state that this tool expects.

I seem to remember it being pretty straightforward to configure the Angular build in the past. This is getting a bit painful tbh.

[alan-agius4]

@Neutrino-Sunset, I suggest you file an issue in their issue tracker with a reproduction.

There isn't anything actionable from our end here, hence I am closing the issue. Feel free to reply.

[timofei-iatsenko]

The fastest way to wean developers to use strict mode in typescript. The development starting from Angular 11 become incredibly annoying. Prior to Angular 11 reported by typescript, errors did not fail the build. Now it fails a build even if it's completely valid JS code (for example unused import or private var)

Developers are lazy people. If the tools don't help and get annoying they just switch them off. There is a case, you even suggesting to switch off "strict mode". What's a shame.

By the way, both webpack and typescript have a way to solve this. Typescript has "noEmitOnError" flag, and ts-loader has "transpileOnly" flag. Only Angular with its own build system is different.

There isn't anything actionable from our end here, hence I am closing the issue. Feel free to reply.

Nothing actionable from Angular Team? What about starting respecting "noEmitOnError" flag from tsconfig, or providing an additional option in angular.json for that purpose?

PS

Developers love typescript because of its flexibility and dynamic nature. It's very fun to prototype, play with code and then solve all errors before commit/going to further task. That favourably distinguishes it from other strict typed languages.

With this "improvement" we completely lose the benefit to be dynamic and agile. Nice job. Thanks.

[alan-agius4]

Hi @thekip,

Thanks for reaching out.

@alexeagle sometime ago mentioned to why ignoring TypeScript errors is the wrong approach. You can read more about this here #11652 (comment).

With regards to your comment.

Developers love typescript because of its flexibility and dynamic nature. It's very fun to prototype, play with code and then solve all errors before commit/going to further task. That favourably distinguishes it from other strict typed languages.

IMHO, in this case the problem is the developers mindset, where it is better to start writing correct or as close to correct TypeScript code from the beginning and fixing errors as they go, as this will also improves the experiencing in the IDE as one avails of the full feature set of the TypeScript and Angular Language Service. Example, when not typing the parameters, using any etc..., you will start quickly loosing out of such features. That said worst case one can use @ts-ignore and @ts-check can be used as an escape hack.

With regards to noUnusedLocals and noUnusedParameters, I agree that these options can be disruptive and we don't include these options in Angular CLI projects and are not in use in our code bases. Using these options might not be as beneficial as one might think. They actually provide little to no benefit, as TypeScript will not emit any unused imports, and unused parameters will later be dropped by terser during the optimization phase.

[timofei-iatsenko]

The issue has nothing in common with "developers mindset" you mentioned and I didn't mean "muting" typescript errors.
I personally have the mindset - "stricter checking - easier life". So in my projects usually all possible checks are enabled, because they really make my life easier, it makes me much more confident in my code.

The problem is when I developing a feature or fixing a bug in the daily routine I want to play with code. For example, add one more required parameter to a method used in a dozen places. But in that moment i worked in one exact file in one exact component and page. I want to build, prove that it works and then go to other files/pages/components one by one and fix errors caused by this change.

Today if i want to make this change i need to go and edit dozens of files before i even can see any changes in the browser. And probably do it again to revert all this because that just doesn't work. This code (broken) will never be committed and shown to anyone except myself. It lives only while developing.

With regards to noUnusedLocals and noUnusedParameters, I agree that these options can be disruptive and we don't include these options in Angular CLI projects and are not in use in our code bases. Using these options might not be as beneficial as one might think. They actually provide little to no benefit, as TypeScript will not emit any unused imports, and unused parameters will later be dropped by terser during the optimization phase.

You looking at this only from one side. From the side of bundle size optimization. These options help to maintain codebase clean. Just imagine you have a service which included in 10 files but actually not used. You look at this file and think, well it's probably not used, can I delete this? Doing Right Click -> Find All usages, well it's still imported in 10 places. The regular developer just stopped here and leave this dead code in the codebase for the next more "brave" developer.

[timofei-iatsenko]

For myself, i fixed the issue just added

    optimization: {
      noEmitOnErrors: false,
    },

In my extra webpack.config (i'm using @angular-builders/custom-webpack)

But i would like to see this option exposed in angular.json (because not all my projects has a custom wepack config)

[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.}