6 ms·

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effect

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever typescript version is hidden inside your bundler, good luck dealing with constant mismatches when there are errors on either side. EDIT: The responses pointed out that the author is the maintainer of webpack, I removed that part of the comment calling it deceptive. Maybe the entire intent is to deprecate webpack. I still think that it should be renamed to "Turbopack: our webpack successor" because calling it 'the' successor is a bit presumptuous and the article doesn't even directly say that.

victorvosk 4y ago
Why would you want your tooling to be coupled when it doesn't have to be with zero downside?
- Nathanba 4y ago
  I outlined some of the downsides in the comment, more in another comment of mine. I thought about it even more and I think I can finally see the possibly true reason why people are developing these type of bundlers: The typescript projects that they have to work on are so huge that the typechecking is always going to be too slow so you don't want to deal with it, you rather typecheck only the file that you're currently working on and you don't care about the 15000 other files because you didn't touch them since checkout and the reasonable assumption is that they will probably still work same as tested by some other team that worked on them and committed them. However there is still one large implication: Your production build on the CI server must then at least be configured to execute both the typechecking process and then the bundling process. I still wonder though: if the typechecking is truly too slow then wouldn't it also be too slow for your iterative development. I guess if those other sections of the code are never referenced then maybe it will do okay and you don't get squiggly lines on all your imports because it won't recheck them? I have some doubts that the typescript type checker actually caches this type of work. It is also strange because somehow every other language in the world doesn't have to separate type checking from compilation, it's only in the js world that we somehow ended up with such large amounts of code that people felt that they want that speed back from back when js could simply be loaded into the browser instantly with no compilation. And on top of that: If Turbopack does such supposedly excellent caching now, why would this not help with a 15000 file project and let me also do typechecking in a cached way? Yes I really don't think that omitting typechecking is the way to go for development.
  - aaomidi 4y ago
    Typescript has an open bug to use multiple threads for compilation. That's why it's slow. It's also not a big deal because of parallel type checkers. > Yes I really don't think that omitting typechecking is the way to go for development. You've not really given a reason why. Just a rant about how other languages are different.
    - Nathanba 4y ago
      It is you who is ranting at me with this small comment complaining about a lack of reasons while I've given many reasons now across multiple comments while you have called me a ranter with two dismissive lines.
  - hamandcheese 4y ago
    For typical workflows, I’m not looking for type errors on the CLI. I’m just running webpack in watch mode in the background, while I edit and get typescript errors in my editor. This is how the majority of people write typescript, and there is only upside from splitting out bundling and type-checking for these people.
rizky05 4y ago
darepublic 4y ago
As others have said, the convention is to use tsc for typechecking and declaration file generation and babel (ie by way of webpack) for bundling. You should not have typescript mismatch issues if you follow good practices. You should get no mismatch with babel using one typescript version and your tsc command using another. Do not use a global tsc command for instance, typescript belongs as a dev dependency in your project
phplovesong 4y ago
Thats not how one usually work. Whats the point in running tsc (the official transpiler) on each save? Plus, you are using an LSP client right? right?? Im a user of esbuild, and its so fast it can recompile on each save (see esbuild `serve` option) and i wont notice anything locally. Theres also a watch mode, and production build with minify. So i work locally without a typecheck for my builds, and let my LSP client do the type checking. When i bundle for prod i run an additional tsc for type checks before the bundle is produced. Takes a few secs more (as tsc is slow) but this is a nonissue.
- Nathanba 4y ago
  I recompile on every save too, all with full typechecking in under a second. As I've suspected, this is probably because most people here work in bigcorp projects where there are so many thousands of files that you cant work like this anymore. It's not because it's actually better workflow wise, it's only better for you now because otherwise the compilation is too slow. Same as the situation that has developed with Rust.
  - Vinnl 4y ago
    I don't, and I think maybe you should reconsider your assumptions about literally every single person replying. Your assumption (from your first comment) is that people only run bundling. That's not the case. People run bundling in parallel to type checking, rather than in series. You still get the type checking benefits without blocking your build on it and thus slowing down your dev process.
    - Nathanba 4y ago
      >Your assumption (from your first comment) is that people only run bundling that was never my assumption
      - Vinnl 4y ago
        Did sound like it: > why would anyone want only bundling
deleted 4y ago
[deleted]
dietmtnview 4y ago
use webpack for bundling and typescript for typechecking. not that far off from the typescript + babel workflow and way less overhead. just use tsc as a linter. https://iamturns.com/typescript-babel/ https://iamturns.com/typescript-babel/ and someone else pointed out that esbuild drops typechecking. https://news.ycombinator.com/item?id=33336803 https://news.ycombinator.com/item?id=33336803
- Nathanba 4y ago
  >use webpack for bundling and typescript for typechecking This is my point, that's what I'm doing. Webpack does the typechecking and the bundling together, you don't get broken bundles when the typecheck didn't succeed (unless you really want to, you can configure that too). >and someone else pointed out that esbuild drops typechecking. yes I know, these "faster" bundlers all drop typechecking which results in these unfair comparisons. Then I always end up spending a somewhat large amount of time checking these tools out only to realize that they are not doing a fair comparison.
  - dietmtnview 4y ago
    > you don't get broken bundles when the typecheck didn't succeed ah, I do TDD. easier to let tests give me runtime and behavioral feedback instead of refreshing/setting up hot reloads. I could see how it's frustrating without that. super frustrating to do a quick experiment/demo and satisfy ts if the compiler breaks all the time tho.
    - Nathanba 4y ago
      >super frustrating to do a quick experiment/demo and satisfy ts if the compiler breaks all the time tho. the ts compiler doesn't break though, I think if I understand you correctly then this might be a relict of javascript-tier thinking/workflow. You're saying that you don't want to deal with the typechecks sometimes, that's not how any other language works. You're essentially saying that you want a build that silently works anyway because you know better than typescript, you know this will still result in correct js even though the compiler is shouting errors at you. I think this is not the right way to look at this, if this is really a very common usecase then Typescript has failed to make truly useful optional typing. Which is actually something I've believed from the start, I was always perplexed when they claimed to be javascript compatible when that doesn't seem to be true at all, you cannot actually genuinely mix pure untyped js and ts code and have it all work seamlessly together. It always complains about adding any types and so on.
bichiliad 4y ago
Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time. If you use Babel with Webpack, for example, Babel just strips out your TypeScript annotations and calls it a day. All that aside, it seems like Turbopack was literally developed with Webpack's maintainer, who claims it to be a "rust-powered successor to webpack" (his signature is quite literally on the homepage[0]). [0]:https://turbo.build/pack https://turbo.build/pack
- Nathanba 4y ago
  >Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking and you have to wait for the IDE based type checker anyway. On every build. It just doesn't make sense to work this way, you never want a fast, silently broken build which is what you get with non-typechecked fast builds.
  - peterhunt 4y ago
    No, webpack became popular because it was the only bundler that supported commonjs and handled code splitting reasonably well, so we picked it for React. It's critical to run type checking outside of webpack. You should be able to execute code that does not type check correctly. It maximizes iteration speed and is one of TypeScript's key superpowers.
  - bmy78 4y ago
    JavaScript is a dynamically-typed language. Parallelizing the type checking with bundling gives you the best of both worlds: the speed when writing in a dynamic language and the type safety that comes with a static-typed language. For me, I like to write my code and not too concern myself with types until I’m close to committing; that’s when I fix type errors.
notpushkin 4y ago
According to the article, the project is “led by the creator of Webpack” (but I'm not sure this means they can name it as the “blessed” successor).
- ludwigvan 4y ago
  Yes. Webpack is essentially going to get deprecated/unmaintained over time from what I understand, so I think it is fair the author names this the successor.

victorvosk 4y ago

Why would you want your tooling to be coupled when it doesn't have to be with zero downside?

Nathanba 4y ago
I outlined some of the downsides in the comment, more in another comment of mine. I thought about it even more and I think I can finally see the possibly true reason why people are developing these type of bundlers: The typescript projects that they have to work on are so huge that the typechecking is always going to be too slow so you don't want to deal with it, you rather typecheck only the file that you're currently working on and you don't care about the 15000 other files because you didn't touch them since checkout and the reasonable assumption is that they will probably still work same as tested by some other team that worked on them and committed them. However there is still one large implication: Your production build on the CI server must then at least be configured to execute both the typechecking process and then the bundling process. I still wonder though: if the typechecking is truly too slow then wouldn't it also be too slow for your iterative development. I guess if those other sections of the code are never referenced then maybe it will do okay and you don't get squiggly lines on all your imports because it won't recheck them? I have some doubts that the typescript type checker actually caches this type of work. It is also strange because somehow every other language in the world doesn't have to separate type checking from compilation, it's only in the js world that we somehow ended up with such large amounts of code that people felt that they want that speed back from back when js could simply be loaded into the browser instantly with no compilation. And on top of that: If Turbopack does such supposedly excellent caching now, why would this not help with a 15000 file project and let me also do typechecking in a cached way? Yes I really don't think that omitting typechecking is the way to go for development.
- aaomidi 4y ago
  Typescript has an open bug to use multiple threads for compilation. That's why it's slow. It's also not a big deal because of parallel type checkers. > Yes I really don't think that omitting typechecking is the way to go for development. You've not really given a reason why. Just a rant about how other languages are different.
  - Nathanba 4y ago
    It is you who is ranting at me with this small comment complaining about a lack of reasons while I've given many reasons now across multiple comments while you have called me a ranter with two dismissive lines.
- hamandcheese 4y ago
  For typical workflows, I’m not looking for type errors on the CLI. I’m just running webpack in watch mode in the background, while I edit and get typescript errors in my editor. This is how the majority of people write typescript, and there is only upside from splitting out bundling and type-checking for these people.

rizky05 4y ago

darepublic 4y ago

As others have said, the convention is to use tsc for typechecking and declaration file generation and babel (ie by way of webpack) for bundling. You should not have typescript mismatch issues if you follow good practices. You should get no mismatch with babel using one typescript version and your tsc command using another. Do not use a global tsc command for instance, typescript belongs as a dev dependency in your project

phplovesong 4y ago

Thats not how one usually work. Whats the point in running tsc (the official transpiler) on each save? Plus, you are using an LSP client right? right?? Im a user of esbuild, and its so fast it can recompile on each save (see esbuild `serve` option) and i wont notice anything locally. Theres also a watch mode, and production build with minify. So i work locally without a typecheck for my builds, and let my LSP client do the type checking. When i bundle for prod i run an additional tsc for type checks before the bundle is produced. Takes a few secs more (as tsc is slow) but this is a nonissue.

Nathanba 4y ago
I recompile on every save too, all with full typechecking in under a second. As I've suspected, this is probably because most people here work in bigcorp projects where there are so many thousands of files that you cant work like this anymore. It's not because it's actually better workflow wise, it's only better for you now because otherwise the compilation is too slow. Same as the situation that has developed with Rust.
- Vinnl 4y ago
  I don't, and I think maybe you should reconsider your assumptions about literally every single person replying. Your assumption (from your first comment) is that people only run bundling. That's not the case. People run bundling in parallel to type checking, rather than in series. You still get the type checking benefits without blocking your build on it and thus slowing down your dev process.
  - Nathanba 4y ago
    >Your assumption (from your first comment) is that people only run bundling that was never my assumption
    - Vinnl 4y ago
      Did sound like it: > why would anyone want only bundling

deleted 4y ago

[deleted]

dietmtnview 4y ago

use webpack for bundling and typescript for typechecking. not that far off from the typescript + babel workflow and way less overhead. just use tsc as a linter. https://iamturns.com/typescript-babel/ https://iamturns.com/typescript-babel/ and someone else pointed out that esbuild drops typechecking. https://news.ycombinator.com/item?id=33336803 https://news.ycombinator.com/item?id=33336803

Nathanba 4y ago
>use webpack for bundling and typescript for typechecking This is my point, that's what I'm doing. Webpack does the typechecking and the bundling together, you don't get broken bundles when the typecheck didn't succeed (unless you really want to, you can configure that too). >and someone else pointed out that esbuild drops typechecking. yes I know, these "faster" bundlers all drop typechecking which results in these unfair comparisons. Then I always end up spending a somewhat large amount of time checking these tools out only to realize that they are not doing a fair comparison.
- dietmtnview 4y ago
  > you don't get broken bundles when the typecheck didn't succeed ah, I do TDD. easier to let tests give me runtime and behavioral feedback instead of refreshing/setting up hot reloads. I could see how it's frustrating without that. super frustrating to do a quick experiment/demo and satisfy ts if the compiler breaks all the time tho.
  - Nathanba 4y ago
    >super frustrating to do a quick experiment/demo and satisfy ts if the compiler breaks all the time tho. the ts compiler doesn't break though, I think if I understand you correctly then this might be a relict of javascript-tier thinking/workflow. You're saying that you don't want to deal with the typechecks sometimes, that's not how any other language works. You're essentially saying that you want a build that silently works anyway because you know better than typescript, you know this will still result in correct js even though the compiler is shouting errors at you. I think this is not the right way to look at this, if this is really a very common usecase then Typescript has failed to make truly useful optional typing. Which is actually something I've believed from the start, I was always perplexed when they claimed to be javascript compatible when that doesn't seem to be true at all, you cannot actually genuinely mix pure untyped js and ts code and have it all work seamlessly together. It always complains about adding any types and so on.

bichiliad 4y ago

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time. If you use Babel with Webpack, for example, Babel just strips out your TypeScript annotations and calls it a day. All that aside, it seems like Turbopack was literally developed with Webpack's maintainer, who claims it to be a "rust-powered successor to webpack" (his signature is quite literally on the homepage[0]). [0]:https://turbo.build/pack https://turbo.build/pack

Nathanba 4y ago
>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking and you have to wait for the IDE based type checker anyway. On every build. It just doesn't make sense to work this way, you never want a fast, silently broken build which is what you get with non-typechecked fast builds.
- peterhunt 4y ago
  No, webpack became popular because it was the only bundler that supported commonjs and handled code splitting reasonably well, so we picked it for React. It's critical to run type checking outside of webpack. You should be able to execute code that does not type check correctly. It maximizes iteration speed and is one of TypeScript's key superpowers.
- bmy78 4y ago
  JavaScript is a dynamically-typed language. Parallelizing the type checking with bundling gives you the best of both worlds: the speed when writing in a dynamic language and the type safety that comes with a static-typed language. For me, I like to write my code and not too concern myself with types until I’m close to committing; that’s when I fix type errors.

notpushkin 4y ago

According to the article, the project is “led by the creator of Webpack” (but I'm not sure this means they can name it as the “blessed” successor).

ludwigvan 4y ago
Yes. Webpack is essentially going to get deprecated/unmaintained over time from what I understand, so I think it is fair the author names this the successor.