You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there an existing issue that is already proposing this?
I have searched the existing issues
Is your feature request related to a problem? Please describe it
When using SWC with NestJS, there is a handy type checking functionality. When there is a type error, you see a log in the console, but the project still compiles successfully.
I originally opened this as a bug, but I have been told this was expected behaviour: nestjs/nest#13760 so I thought it would be a good idea to report this as a feature request instead. You can see a full log example in that issue.
Describe the solution you'd like
When the type check flag is used and there is a type error, the SWC compiler does not compile the project nor show the "Application successfully started" message.
(AFAIK this would be the same behaviour as the compiler without SWC)
This should probably be configured through a new flag/configuration variable to avoid breaking changes for people already using the type check flag.
SWC does not perform any type checking itself (as opposed to the default TypeScript compiler), so to turn it on, you need to use the --type-check flag:
$ nest start -b swc --type-check
If you wish for compilation to fail when using type checking, then you can use the --type-check-fail flag
$ nest start -b swc --type-check-fail
What is the motivation / use case for changing the behavior?
This was the behaviour when using the non-SWC compiler. We got used to relying on the NestJS compilation output log to determine whether we were introducing TS errors and to safeguard us against them.
The text was updated successfully, but these errors were encountered:
We switched from the default compiler to SWC because of speed.
With the default compiler, it got to a point where it took ~2 minutes (on fast machines) to compile the project. With SWC it takes ~2 seconds. On the same project, npx tsc --noEmit takes ~10 seconds.
So (we assumed) something else beyond tsc is slowing down the default compiler and switching to SWC seemed the better approach for our use case, rather than investigating alternative ways to speed things up. But, after a few weeks, we noticed we lost the functionality of type checking being a safeguard during compilation.
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
When using SWC with NestJS, there is a handy type checking functionality. When there is a type error, you see a log in the console, but the project still compiles successfully.
I originally opened this as a bug, but I have been told this was expected behaviour: nestjs/nest#13760 so I thought it would be a good idea to report this as a feature request instead. You can see a full log example in that issue.
Describe the solution you'd like
When the type check flag is used and there is a type error, the SWC compiler does not compile the project nor show the "Application successfully started" message.
(AFAIK this would be the same behaviour as the compiler without SWC)
This should probably be configured through a new flag/configuration variable to avoid breaking changes for people already using the type check flag.
Teachability, documentation, adoption, migration strategy
For example:
Type checking
SWC does not perform any type checking itself (as opposed to the default TypeScript compiler), so to turn it on, you need to use the
--type-check
flag:$ nest start -b swc --type-check
If you wish for compilation to fail when using type checking, then you can use the
--type-check-fail
flag$ nest start -b swc --type-check-fail
What is the motivation / use case for changing the behavior?
This was the behaviour when using the non-SWC compiler. We got used to relying on the NestJS compilation output log to determine whether we were introducing TS errors and to safeguard us against them.
The text was updated successfully, but these errors were encountered: