feat: TypeScript noEmitOnError when is true, stencil running without stops

[mrcodedev]

Prerequisites

• [X] I have read the Contributing Guidelines.
• [X] I agree to follow the Code of Conduct.
• [X] I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

It's necessary that when we have the noEmitOnError typescript property, the compiler does not show errors and Stencil can be executed without stopping.

Describe the Use Case

When you have there is a property that exists but in a model doesn't exist

Describe Preferred Solution

That Stencil pays attention to the noEmitOnError, and that it is the developer who controls if he wants to see errors or not

Describe Alternatives

No response

Related Code

No response

Additional Information

No response

[rwaskiewicz]

Hey @mrcodedev 👋

Can you help me understand this request a little bit more?

It's necessary that when we have the noEmitOnError typescript property, the compiler does not show errors and Stencil can be executed without stopping.

In that case, would the compiler show nothing? In your ideal world where we have this feature, how does a user know that the compilation was successful or has failed?

When you have there is a property that exists but in a model doesn't exist

Can you provide me a code sample example where you're seeing this occur? If I spin up a component library with npm init stencil@latest component my-library, make the following changes to src/components/my-component/my-component.tsx:

  private getText(): string {
+   const foo: number = true;
    return format(this.first, this.middle, this.last);
  }

and run npm run build, I get errors in the console (but nothing is emitted):

[04:53.5]  @stencil/core
[04:53.6]  v2.16.1 🎻
[04:54.4]  build, test, prod mode, started ...
[04:54.4]  transpile started ...
[04:55.5]  transpile finished in 1.06 s

[ ERROR ]  TypeScript: ./src/components/my-component/my-component.tsx:26:11
           Type 'boolean' is not assignable to type 'number'.

     L25:  private getText(): string {
     L26:    const foo: number = true;
     L27:    return format(this.first, this.middle, this.last);

[ ERROR ]  TypeScript: ./src/components/my-component/my-component.tsx:26:11
           'foo' is declared but its value is never read.

     L25:  private getText(): string {
     L26:    const foo: number = true;
     L27:    return format(this.first, this.middle, this.last);

[04:55.5]  build failed in 1.06 s

Is the request here to print something like this if noEmitError is set?

[04:53.5]  @stencil/core
[04:53.6]  v2.16.1 🎻
[04:54.4]  build, test, prod mode, started ...
[04:54.4]  transpile started ...
[04:55.5]  transpile finished in 1.06 s
[04:55.5]  build failed in 1.06 s

If so, can you describe your workflow/how this would be beneficial for you/your team please?

[mrcodedev]

I'm sorry if I could have led you to believe otherwise, but what we need is to be able to speed up our development process without being interrupted by compiler failures. But keep the checks in the build

[tonymartin-dev]

Hi @rwaskiewicz ! Tony here, @mrcodedev 's teammate.

First of all, thanks four your response.

Our situation is something like this:

While you are working in development mode in your ionic application, if you get some kind of typescript error, the proccess breaks and you get this screen

This seems nice, but sometimes it could be useful to be able to disable this error screen in order to avoid interruptions in your development proccess. If you need to check errors, you can always deactivate noEmitOnError and, of course, your npm run build will throw errors anyway.

Maybe noEmitOnError is not the best solution, or maybe it is, I'm not sure really. But I think it could be a great improvement in our workflow.

Following your example, when you insert this line

const foo: number = true;

you wouldn't get any error in your npm start proccess, you can keep working and fix it later. But if you try to run npm run build your compiler will keep getting this errors in console.

Besides all this, i think it may also reduce update times after each save in watch mode.

[adrm]

I want to note that this problem happens because the Stencil compiler reads the tsconfig.json file but overwrites the value of the noEmitOnError property and always forces a true value. As such, there is no way for us users to choose the value of that tsconfig property when using it with the Stencil compiler.

I understand that it might have a default value, and that noEmitOnError: true can be inserted if no value is set, but I don't see a reason to not allow users to set the value they want.

[rwaskiewicz]

Thanks for the clarification all! I'm gonna mark this for folks to upvote if this is something they'd like to see in Stencil

[tfrijsewijk]

Oh yeah this would be great. I often comment out code during debugging/testing which results in "unused variables" or "unused functions". Obviously I want this to fail my build and certainly I want to know this during development, but now it's slowing down my debugging because I also have to uncomment the unused variables/functions.

[alicewriteswrongs]

Just looked into this a little bit and I don't think changing how Stencil handles noEmitOnError would fulfill this feature request, as Stencil actually already sets this to false:

https://github.com/ionic-team/stencil/blob/8f03983a1552d95c67ffbc691cba2742b9f3f593/src/compiler/transpile/ts-config.ts#L23-L37

It's sort of a double-negative situation, but as I understand the TypeScript documentation for noEmitOnError setting it to false is what TypeScript defaults to and should enable emitting code even when there's some type error.

So I think in order to address this feature request we'd need to do some work to distinguish between TypeScript errors and other errors and possibly add a configuration option to ignore typescript errors. This is just to provide some context as to why Stencil behaves this way and why it's a bit more complicated to implement something like this than just respecting a tsconfig.json option, as it's hard to know which errors we could safely ignore and go on to emit code and which we couldn't.