4 ms·

Webpack does not bundle the type checking by default - iirc it cannot handle typescript at all by default, it needs to be configured. The typescript plugin tha

by MrJohz 4y ago

Webpack does not bundle the type checking by default - iirc it cannot handle typescript at all by default, it needs to be configured. The typescript plugin that you used may have included type checking, but it very much depends on how you set it up. Many common setups use Babel to compile typescript code, which doesn't do any type checking at all, just mechanically strips away the type signatures. I would be very surprised if much of webpack's success has come from the type checking functionality you describe. As for whether it's "the only workflow that makes sense", I find the most comfortable flow for me is using the compiler as a linter rather than a "true" compiler. It runs in my IDE, potentially as a pre-commit script, and in CI (which means checked in code cannot fail to type check), but I can still build failing code. This would be, as you say strange if I were using C#, but syntactically valid typescript can always be covered to syntactically valid javascript, so the output won't be "broken" in the same way that a C# program with invalid types would be. Most of the time, a program that isn't accepted by TSC is still a valid javascript program, just with poorly specified input and output types. That said, while it can be useful occasionally if I'm still trying to figure out the types, the advantage here is less that I can now compile invalid code, and more that my bundler doesn't need to do unnecessary type checking. Any errors I can catch myself based on the red squiggles in my editor, so I know not to look at the browser until I've fixed all the issues, and at that point I don't need my bundler to also confirm that the types are accurate. Each tool does one task well. (Similarly, I don't want my bundler to also run all the unit tests before it compiles, even though I would normally expect the tests to be passing before I check the output of my code. 90% of the time, if I run the bundler, my tests are passing, and in the last 10%, I probably want to quickly try something out without changing the tests. The same logic usually applies to my types.) As a result, I strongly disagree with the claim that your process is the only one that makes sense. It may be the most logical for you and your team, but I tend to find that it makes sense to approach typescript from a different angle to most typical compiled languages, and I've found a lot of success in my process.

Nathanba 4y ago
I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files and I haven't figured out how they do that. I doubt it though, I think there is no way. It always complains about lack of types, it wants me to add annotations. The promise of mixing js and ts is not real for me. It just defies belief for me that people actually want to write squiggly line, broken autocomplete type of code and have it compile a tiny bit faster compared to just having a single unified workflow where typing, build output and build information always matches and you don't have to guess and look up whether the build is already done, or maybe there was a build error or maybe this time one of the type checks that I ignored actually mattered for js also, not just for ts or maybe the error was actually not just a typecheck error but also a DOM api error and on and on it goes. To actually want to live in this world of uncertain, mismatched information and expect to be faster iteratively is not believable. How is it not a problem for you that you make a change in a .ts file and then you are immediately in a world of uncertainty: Is the typecheck already complete? No clear progress on this. The js output is probably already here, but not sure unless you constantly want to check yet another terminal window. So can I reload the page yet? Oh no wait, a few more type errors popped up after all, so I can't yet. This all happens in under 2 seconds but those 2 seconds are uncertainty and slow you down far more than any wait for a normal sized typescript project where typechecking is done integrated with the build.
- MrJohz 4y ago
  > I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files[...] I don't think that's it. I write pretty much exclusively typed code, except in places where I've not managed to get everything set up properly (mainly old Vue2 code). And even then, imports are unidirectional: JS can import TS, but TS can only import other TS files. As to the "world of uncertainty", this lasts surely less than 100ms for me, certainly little enough time that it feels instantaneous. Usually I get feedback as I'm typing, sometimes if I'm doing things in new files I need to save the file first, but either way, my IDE is consistently fast enough that I know immediately if my code type checks or not. There is no downtime here at all. As for seeing the code change, I usually have the page open on a second monitor, so I press "save", and glance over to my second monitor, and with live reload and a good configuration (that's harder to achieve on some projects, I grant you), I'm usually already looking at the results of my changes. In practice, I very rarely have any uncertainty about what typescript thinks my types are - this information is always immediately at my fingertips. Where I do have uncertainty sometimes is whether the javascript types match the expected typescript ones - this often happens when I'm dealing with third-party libraries, particularly when `any` types start popping up. In that case, it's occasionally useful to ignore the type checker altogether, play around with some different cases, and then come back to ensuring that the types match later. That's just not really possible if you're treating the type checker and the compiler as an all-in-one unit.
  - Nathanba 4y ago
    >with live reload and a good configuration (that's harder to achieve on some projects, I grant you), right but livereload has the same problem as you: The build is already done so it reloads but lets say the typecheck will error out because surely you save a file more often than you want to recompile. So your page just reloaded which you didn't intend, in fact, it might actively have destroyed a debugging session which you didnt want to reload yet. How do you configure that away to make it work sensibly? And here is the kicker: I know you can configure your livereload build so it only reloads after the build and the typecheck are done. But this is precisely how we ended up discussing this.. now you always depend on both the typecheck and the build to end before you can test your change anyway.

by MrJohz 4y ago

Nathanba 4y ago

I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files and I haven't figured out how they do that. I doubt it though, I think there is no way. It always complains about lack of types, it wants me to add annotations. The promise of mixing js and ts is not real for me. It just defies belief for me that people actually want to write squiggly line, broken autocomplete type of code and have it compile a tiny bit faster compared to just having a single unified workflow where typing, build output and build information always matches and you don't have to guess and look up whether the build is already done, or maybe there was a build error or maybe this time one of the type checks that I ignored actually mattered for js also, not just for ts or maybe the error was actually not just a typecheck error but also a DOM api error and on and on it goes. To actually want to live in this world of uncertain, mismatched information and expect to be faster iteratively is not believable. How is it not a problem for you that you make a change in a .ts file and then you are immediately in a world of uncertainty: Is the typecheck already complete? No clear progress on this. The js output is probably already here, but not sure unless you constantly want to check yet another terminal window. So can I reload the page yet? Oh no wait, a few more type errors popped up after all, so I can't yet. This all happens in under 2 seconds but those 2 seconds are uncertainty and slow you down far more than any wait for a normal sized typescript project where typechecking is done integrated with the build.

MrJohz 4y ago
> I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files[...] I don't think that's it. I write pretty much exclusively typed code, except in places where I've not managed to get everything set up properly (mainly old Vue2 code). And even then, imports are unidirectional: JS can import TS, but TS can only import other TS files. As to the "world of uncertainty", this lasts surely less than 100ms for me, certainly little enough time that it feels instantaneous. Usually I get feedback as I'm typing, sometimes if I'm doing things in new files I need to save the file first, but either way, my IDE is consistently fast enough that I know immediately if my code type checks or not. There is no downtime here at all. As for seeing the code change, I usually have the page open on a second monitor, so I press "save", and glance over to my second monitor, and with live reload and a good configuration (that's harder to achieve on some projects, I grant you), I'm usually already looking at the results of my changes. In practice, I very rarely have any uncertainty about what typescript thinks my types are - this information is always immediately at my fingertips. Where I do have uncertainty sometimes is whether the javascript types match the expected typescript ones - this often happens when I'm dealing with third-party libraries, particularly when `any` types start popping up. In that case, it's occasionally useful to ignore the type checker altogether, play around with some different cases, and then come back to ensuring that the types match later. That's just not really possible if you're treating the type checker and the compiler as an all-in-one unit.
- Nathanba 4y ago
  >with live reload and a good configuration (that's harder to achieve on some projects, I grant you), right but livereload has the same problem as you: The build is already done so it reloads but lets say the typecheck will error out because surely you save a file more often than you want to recompile. So your page just reloaded which you didn't intend, in fact, it might actively have destroyed a debugging session which you didnt want to reload yet. How do you configure that away to make it work sensibly? And here is the kicker: I know you can configure your livereload build so it only reloads after the build and the typecheck are done. But this is precisely how we ended up discussing this.. now you always depend on both the typecheck and the build to end before you can test your change anyway.