fix(angularCompilerPlugin): respect noEmitOnError compiler's option when checking for typescript errors

[Fatme]

Currently noEmitOnError compiler's option is not respected when executing typescript program. In case when noEmitOnError is false and there are compilation errors in project, no .js files are emitted. However, in this case .js files should be emitted.
In case when noEmitOnError is true and there are compilation errors in project, .js files should not be emitted.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[Fatme]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[clydin]

This behavior is intentional and the option is always disabled within the plugin. See:
https://github.com/angular/angular-cli/blob/master/packages/ngtools/webpack/src/angular_compiler_plugin.ts#L221

[DimitarTachev]

Hi @clydin,

Why did you close this?

You are referring a code which sets the noEmitOnError to false in order to allow emitting with errors so that imports can be added.

However, as @Fatme described in this PR, you have manual errors check and the AngularCompilerPlugin does NOT emit any js code even when noEmitOnError is set to false.

Am I getting something wrong or you've just read only the title and didn't review the changes at all?

[clydin]

Please be aware that disrespectful and/or unprofessional language is a violation of the code of conduct by which this and all other projects within the organization abide.

This is closed because the current behavior is intentional. Adding broken code to the bundling pipeline can cause a cascade of errors that are confusing and difficult to diagnose. Further the link to the code also demonstrated that the change within this PR will cause code to always be emitted regardless of the value set in the project's tsconfig or the presence of errors as it is hard coded to be false.

[DimitarTachev]

@clydin

Thanks for the fast and more detailed comment!

I'm sorry you've felt disrespected, I just didn't get the connection between your answer and the PR content.

It looks like we will have to accept this as a known Limitation of the plugin but I believe that not emitting any js regardless of the noEmitOnError value is leading to much more confusion and its much harder to debug.

What do you think about overriding this behavior through the AngularCompilerPlugin options?

For example something like:

new AngularCompilerPlugin({
  ...
  emitOnTsError: true
});

[clydin]

Every additional option adds a long-term sustainment cost in both time and resources. In this case, the team believes that correcting any errors within the application would be the more beneficial and prudent action in both the short and long term. However, if a compelling use case for this behavior is presented, a change in direction would be considered.

[DimitarTachev]

Thanks for the detailed statement!

We will consider opening another PR with more details and use cases.

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