Ember-cli-typescript: Disable type checking in ember build

[mschorsch]

First of all thanks for this wonderful addon.

I have a question. Is there a way to disable type checking in ember-cli-typescript v1 or in v2?

As far as I can see, babel 7 does not do any type checking. Therefore, it should be possible to disable it (v2 only).

Advantage: The build times could be significantly reduced. Type checks are performed by the IDE (VS code, Intellij, ...).

[mike-north]

Type checks are performed by the IDE

This is typically only true for open files. If you want to benefit from type-checking, it's important that you have it as part of your build process

[chriskrycho]

Also note that in v2, since the build runs through Babel and we split the type-checking off into its own process, you shouldn't see significant increases in build time from using TypeScript any more. On a ~60,000 lines-of-TS code I worked on up until the end of January, there was no impact on the total build times using the v2 RCs. (I can't say if that holds universally, but it's a useful point of data.)

[mschorsch]

Thanks for the quick response :).

I'm working on a project of similar size (~ 80,000 LoC).

As part of the issue we examined the times for the type checks. With the following result:

• Typescript v3.0.3: 40 seconds
• Typescript> = v3.1: ~ 6-8 minutes

With the workaround described in issue we were able to reduce the times for the type checks to 7 seconds. In each case, it was measured by tsc --diagnostics. This times seem to us sufficiently fast for the time being.

The ember rebuild times (ember s) for a warm build still seem too high. Currently the rebuild times are between 9 and 12 seconds. 7 seconds are spent on type checks.
During development, it would be advantageous to disable the type checks and leave the type checking to the IDE. If necessary, a full type check can be triggered manually within the IDE. CI builds can still perform type checks as usual.

We have another project based on react of similar size. By setting the transpileOnly flag, the rebuild times went down from ~10 seconds to 2 seconds.

We think that the same strategy could help here in the current case.

[mike-north]

@mschorsch did you happen to upgrade the @types/ember* packages during your v1 -> v2 changes, or is this an apples-to-apples comparison?

[mschorsch]

@mike-north I think all typings are up to date. I'll check that again tomorrow.

[mike-north]

@mike-north I think all typings are up to date. I'll check that again tomorrow.

What I'm asking is

• Typescript v3.0.3: 40 seconds
• Typescript> = v3.1: ~ 6-8 minutes

Were these measurements taken using the same version of the types?

[mschorsch]

Were these measurements taken using the same version of the types?

Yes, but i'm not sure if this was done with the latest typings. I will check this again tomorrow.

[chriskrycho]

That difference between 3.0.3 and 3.1 matches our general understanding of the performance regression around a number of things involving mapped and conditional types (per the issue you linked above).

We don't currently have a mechanism for disabling all type-checking in any development phase, simply because that seems to defeat the purpose. However, we've also seen that some teams prefer to use the type-checking step as a pre-commit or pre-merge "lint"-style check, and having a setting that controls that might be useful.

[mschorsch]

Ok, I checked the times for the type checks again. All tests were performed by tsc --diagnostics with the lastest typings (@types/ember*).

With the workaround from https://github.com/typed-ember/ember-cli-typescript/issues/337 I get the following times:

• ~8s (v3.0.3)
• ~8s (v3.1.6)
• ~7s (v3.2.4)
• ~7s (v3.3.3)
• ~7s but with build failures (v3.4.0-dev)

Without the workaround:

• ~66s (v3.0.3)
• ~556s (v3.1.6)
• ~623s (v3.2.4)
• ~584s (v3.3.3)
• ~7s but with build failures (v3.4.0-dev)

[chriskrycho]

Thanks for the confirmation – and that matches what we'd expect from that issue. As noted, it's upstream, so there's little we can do about it at present. 😢 Not later than next week, I'm going to open an issue on TS proper which I hope they'll find actionable.

[chriskrycho]

@mschorsch just a quick update here: for the moment I'm going to mark this as potentially going into the 2.1 release, as I don't think it should be a blocker for our 2.0 release. That means it's not likely to see a ton of attention in the next few weeks as we're tackling things which are blockers for that, but we will circle back around to and at a minimum decide whether or not we want to support it after we get 2.0 out the door!

[buschtoens]

Hey :wave:

I think I asked about this in Discord a few months ago, but personally I'm still highly interested in being able to turn off the type checking. Especially now, that the actual transpilation is moving to ember-cli-babel itself, but can (currently) only be opted into by installing ember-cli-typescript, I think it becomes even more valuable.

My use case is a huge legacy application, with lots of broken .ts files. Our current method of fixing this is to extract / rewrite chunks into extra packages. The new packages are 100 % type error free, but the legacy app is not and never will be. It's a waste of local CPU resources and CI runtime to run the type checker.

This is also very true when you just want to run ember build for CD, and have verified type validity in a prior CI step already. If accepted, I'd be happy to PR this.

[chriskrycho]

A genuine question: in the case of that “is not and never will be” application, what’s the value that TS is adding for you? In the scenario you’re describing, I would actually recommend just using JS for those packages, while continuing to do TS in the new packages as you extract them. That’d still give you most of the benefits of TS while minimizing your pain of using it: just have a jsconfig.json file that tells TS how to understand the JS files and get all that good feedback.

(I do want to support using TS however people actually are using it, I just think that the above is a much happier path.)

I totally understand your and others’ pain here, and it’s not always obvious to most people when getting started that this is a recipe for pain. However, I’m loathe to add this functionality right now… given we’re in the process of moving to a world where you’d be able to have transpilation without typechecking on a per-package basis just by installing ember-cli-typescript or not for that package.

I’d be curious to hear others’ thoughts, though. @jamescdavis @dfreeman @mike-north?

[dfreeman]

I would actually recommend just using JS for those packages, while continuing to do TS in the new packages as you extract them.

That's exactly the route I would go as well.

That said, it seems reasonable to me to have a flag you could set in your ember-cli-babel config that it checks first before falling back to its default "is ember-cli-typescript present" decision-making process for whether to transpile TypeScript.

[buschtoens]

The reason is that around 85 % of all JS source files in the legacy app are .ts and most of them actually also use TS syntax. These files vary a lot in their code quality and type validity. Some are totally fine and would simply be moved, when extracted, while others need a bit of fixing, and some require a rewrite from scratch.

What I would _love_ to do is strip all TypeScript syntax from any .ts files which have more than x errors per LOC. This would leave us with a manageable amount of just slightly broken .ts files, which should be easier to fix iteratively.

However, I could not find such a tool, and did not have the time yet to write it myself. I also wouldn't want to blindly strip TypeScript from all files, since this would also remove it from files which are perfectly or almost fine.

To make matters worse, we actually have so many type errors, that the type checker IPC connection regularly dies in CI.

Anyhow, unrelated to this, I think the desire to not type check for CD builds is very valid. Personally I actually prefer to do the type checking with tsc --noEmit anyway.

[jamescdavis]

@buschtoens https://github.com/babel/ember-cli-babel/pull/314/commits/7c6db1500b9fdd875aab8f915201dab5262e86e6 😃

[buschtoens]

@jamescdavis it's not even Christmas yet. Thanks! 😍

[jamescdavis]

[email protected] has been released with this functionality!

Docs: https://github.com/babel/ember-cli-babel#enabling-typescript-transpilation

TL;DR?

  let app = new EmberApp(defaults, {
    'ember-cli-babel': {
      enableTypeScriptTransform: true
    }
  }

and remove ember-cli-typescript.