Hi folks! The ember-cli-typescript maintainers are evaluating our options for continuing to improve the performance, ergonomics and stability of the addon in light of some doors the impending Babel 7 release opens. We’re hoping to gather a little data about how you’d like to be using the addon when it comes to type errors. In an ideal world, would a TypeScript type error during your normal development flow cause the build to fail?
Yes, I’d like the build to explode and make it clear to me that I’ve broken something
No, I’d rather typecheck separately from the normal build flow (e.g. run tsc by hand and/or in CI)
No, I don’t care about type errors
I’m not sure; I’ll likely just do whatever the default is
0voters
To be clear, we’re not discussing forcing this behavior on anyone, only asking whether in your ideal workflow, it would be the case. If you have specific thoughts beyond just answering the poll, we’d love to hear them!
I have a bunch of silly things in my app, like ember-concurrency with decorators. No idea how to type that stuff. I’d be sad if my build stopped succeeding because of those errors.
Ideally it would be configurable, but I think warning on type errors is better while converting apps. There will be type errors, but I want to be able to run tests and make sure I am not breaking anything while working on them.
To be clear, this poll is not about taking away to ability to build when there are TypeScript errors, just how important is it to continue to have the ability to fail the build on TypeScript errors, if one so chooses.
+1 for being configurable, but I think it should default to exploding. If I’m starting a new TS project, I want the safety guards on from the start, so I don’t have to go back and fix a bunch of errors I didn’t notice along the way.
And @NullVoxPopuli, silly untypeable things are what any is for
this poll is not about taking away to ability to build when there are TypeScript errors
Whoops, that wasn’t clear to me in the selection - I voted for NO only because that was a better option than the build breaking by default IMO. But I would definitely be in favor of a configuration setting that allows for the build to be broken on type errors. I still don’t think I’d ship it enabled though, I think setting them as warnings would be an appropriate default.
If we were in a world where type errors would really be type errors because we caused them, my answer would be yes. Since we aren’t, I my answer is no. Though I help getting into this world
TLDR type errors should fail build on CI server, but should not block local development
I think the ideal case is that type errors should never prevent you from making changes and seeing them in the browser. If you are trying to rapidly prototype something and you aren’t quite sure of the implementation, the last thing you want to do is have to invest a bunch of time into getting the types perfect. You do however want type errors to fail the build on CI so you don’t accidentally merge failing types into master. It’s best to think of them as unit tests or really powerful lint tools in this way.
The point about them being missed in development is a valid one though. Perhaps it would be great if the CLI printed errors to the terminal, as well as (if possible) to the browser console after the live reload.
It might even be good if the default behavior was to fail the build and print the build failure to the screen the way that create-react-app-ts does
Yeah I agree with you and changed my vote too. The case where you are “converting” an app it’s nice to just have the build show you the next error that you need to work on.
I guess it’s just a question of what the default behavior should be.
In an ideal world I would like the option for builds to fail on type errors.
But…
Does this mean that using Babel 7 to transpile will make it hard to have the build error? If there were a bunch of other advantages (e.g. faster compilation, more stable compilation, simpler code within ember-cli-typescript etc) then I wouldn’t say it’s essential.
If there were a bunch of other advantages (e.g. faster compilation, more stable compilation, simpler code within ember-cli-typescript etc) then I wouldn’t say it’s essential.
That’s essentially the tradeoff we’re exploring
Given the response here, though, I think we’ll likely prioritize finding a way to keep the “type error == hard failure” option around, as long as we can do it without imposing a major perf hit. I don’t think that’s a surprising outcome, but we wanted to make sure we understood the community needs before investing in solving this particular problem.
I think of type errors like lint errors. I always keep my ember serve window up on the side and I always want to see that they’re present. Like lint errors, it’s good for them to appear in /test so they form part of the “we agreed not to check in until /test comes back with zero failures” discussion. I would only want them to fail cold the build we deliver to CI, which they could do as a side-effect of running test in the build.
I know this is an old thread but I just started converting my Ember project to TypeScript and want to fail my build if tsc finds errors. Is it possible to do that at this point?
Excellent! I have one small suggestion for the “Using Ember Effectively” section on noEmitOnError. I read that before posting my question but it was not clear to me that setting that flag would actually fail the build. Adding “Set this flag to fail the build” would make it very clear even to me
