4 ms·

Is Bun executing TS or is it also compiling down to JS and executing that? Edit: The docs mention: > Because Bun can directly execute TypeScript, you may not

by pier25 3y ago

Is Bun executing TS or is it also compiling down to JS and executing that? Edit: The docs mention: > Because Bun can directly execute TypeScript, you may not need to transpile your TypeScript to run in production. Bun internally transpiles every file it executes (both .js and .ts), so the additional overhead of directly executing your .ts/.tsx source files is negligible. https://bun.sh/docs/runtime/typescript https://bun.sh/docs/runtime/typescript The idea I'm getting from this is that both JS and TS are transpiled to something else. Are types preserved in this bytecode, AST, or whatever it is?

emmanueloga_ 3y ago
"TypeScript & JSX support. You can directly execute .jsx, .ts, and .tsx files; Bun's transpiler converts these to vanilla JavaScript before execution." -- https://bun.sh/docs#design-goals https://bun.sh/docs#design-goals
Kognito 3y ago
It’s not running TS directly, it’s just preconfigured to transpile TS to JS without the user having to bring extra tooling. Neat, but you’ll see the docs still recommend tsc for type checking at build.
- galaxyLogic 3y ago
  I wonder what's the benefit of TS if there's no type-checking? If types are not checked that means the TS type-declarations could be totally wrong and nobody would know. In other words they could be misleading. Why incur the type-declaration overhead if they are not used after all?
  - pfg_ 3y ago
    This is how typescript is run today. Typescript types never exist at runtime regardless of how typescript is run. There is no overhead defining types because they are deleted at runtime. The purpose of typescript is to make the editor experience better (autocomplete, error highlight). Typically typechecking is run in addition to tests to make sure there aren't a bunch of errors no one saw in editor.
    - galaxyLogic 3y ago
      So "type-checking is run". Could it not be run by Bun automatically?
      - noahtallen 3y ago
        It could be, but even today without Bun, a common approach is to do type checking in a separate step from the build. This is because tsc doesn’t parallelize well, so type checking will slow down the build a lot. So you can put the type check step in a separate CI job, and have it fail like unit tests would. Then the main build can be a lot faster since it just has to strip the annotations. Plus, for local dev, iteration and watch/rebuild is more important than failing with invalid types on every change. Sometimes it’s helpful to circle back to fix/update types after you’ve tried a couple approaches. (TS can still be finicky at times!) On top of that, your IDE should report type errors as you work anyways.
        galaxyLogic 3y ago
        Makes sense. I would still prefer though that Bun did it for me, in a separate process perhaps, so I wouldn't need to configure a separate CI job, or manually enter the tsc-command. I read that Bun has its own test-runner too so why not its own type-checker too. On Node.js I just edit the source-code then re-start the debugger on it, and edit it while in the debugger then rinse and repeat. I use runtime assertions to catch errors in argument-types etc. as needed.
        nsonha 3y ago
        the only time you run type-checker is on CI. For the majority of the time you only need the code to compute and your editor/IDE should already have its own bundled type-checker. Unless bun has its own type-checker which means it has to play catch-up with tsc (if that's even possible, typescript's type system is very complex), I don't find a lot of benefit for Bun to merely call tsc for me.
vbezhenar 3y ago
Transpiling TS is really easy task, because TS developers made huge effort to make it possible. You basically remove all types and that's about it. Probably could be done with simple character streaming algorithm. At this point, IMO, it should just be implemented within V8. Would make things much simpler for everyone.
- whstl 3y ago
  Totally agree. There is a TC39 proposal for that: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
  - MrResearcher 3y ago
    That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme-ov-file#how-does-this-proposal-relate-to-typescript https://github.com/tc39/proposal-type-annotations?tab=readme...
    - whstl 3y ago
      Hmmm good catch. But on the other hand, it would be already fantastic to have at least a subset of TypeScript...
    - WorldMaker 3y ago
      It is more compatible than not and there are workarounds for most of the things that wouldn't work, many of which you shouldn't be using in Typescript today, have known workarounds (enums), and/or you probably have lint rules already warning against using (namespaces). (There are more details elsewhere in that proposal document outside of the direct linked FAQ question.)
      - whstl 3y ago
        Great point. It is 100% possible to survive without enums and namespaces. And in fact: I bet the Typescript team itself would deprecate them (or at least add extra checks to TS to avoid them) if the TC39 proposal above passed.
Jarred 3y ago
Bun transpiles Typescript to JavaScript before execution, removing types and doing some dead code elimination
crabmusket 3y ago
> or is it also compiling down to JS and executing that? This is the only way to execute TypeScript. That's how every tool that "executes" TypeScript works.
- erhaetherth 3y ago
  I don't buy it. That might be how every tool today works, but there's no reason V8 or whatever can't run TS the same way it runs JS.
  - crabmusket 3y ago
    If it runs TS "the same way" it runs JS then how is that different to what I described? It would be a JS engine that strips the types before execution. There is a persistent fantastical hope that TS can somehow be a compiled language. It can't, not without breaking compatibility with JS. Until, of course, someone manages to compile JS - but at that point TS would be irrelevant. I say this as someone who loves TS and wouldn't want to be without it: TS is a fancy linter. JS defines the execution semantics of the language.

by pier25 3y ago

emmanueloga_ 3y ago

"TypeScript & JSX support. You can directly execute .jsx, .ts, and .tsx files; Bun's transpiler converts these to vanilla JavaScript before execution." -- https://bun.sh/docs#design-goals https://bun.sh/docs#design-goals

Kognito 3y ago

It’s not running TS directly, it’s just preconfigured to transpile TS to JS without the user having to bring extra tooling. Neat, but you’ll see the docs still recommend tsc for type checking at build.

galaxyLogic 3y ago
I wonder what's the benefit of TS if there's no type-checking? If types are not checked that means the TS type-declarations could be totally wrong and nobody would know. In other words they could be misleading. Why incur the type-declaration overhead if they are not used after all?
- pfg_ 3y ago
  This is how typescript is run today. Typescript types never exist at runtime regardless of how typescript is run. There is no overhead defining types because they are deleted at runtime. The purpose of typescript is to make the editor experience better (autocomplete, error highlight). Typically typechecking is run in addition to tests to make sure there aren't a bunch of errors no one saw in editor.
  - galaxyLogic 3y ago
    So "type-checking is run". Could it not be run by Bun automatically?
    - noahtallen 3y ago
      It could be, but even today without Bun, a common approach is to do type checking in a separate step from the build. This is because tsc doesn’t parallelize well, so type checking will slow down the build a lot. So you can put the type check step in a separate CI job, and have it fail like unit tests would. Then the main build can be a lot faster since it just has to strip the annotations. Plus, for local dev, iteration and watch/rebuild is more important than failing with invalid types on every change. Sometimes it’s helpful to circle back to fix/update types after you’ve tried a couple approaches. (TS can still be finicky at times!) On top of that, your IDE should report type errors as you work anyways.
      - galaxyLogic 3y ago
        Makes sense. I would still prefer though that Bun did it for me, in a separate process perhaps, so I wouldn't need to configure a separate CI job, or manually enter the tsc-command. I read that Bun has its own test-runner too so why not its own type-checker too. On Node.js I just edit the source-code then re-start the debugger on it, and edit it while in the debugger then rinse and repeat. I use runtime assertions to catch errors in argument-types etc. as needed.
        nsonha 3y ago
        the only time you run type-checker is on CI. For the majority of the time you only need the code to compute and your editor/IDE should already have its own bundled type-checker. Unless bun has its own type-checker which means it has to play catch-up with tsc (if that's even possible, typescript's type system is very complex), I don't find a lot of benefit for Bun to merely call tsc for me.

vbezhenar 3y ago

Transpiling TS is really easy task, because TS developers made huge effort to make it possible. You basically remove all types and that's about it. Probably could be done with simple character streaming algorithm. At this point, IMO, it should just be implemented within V8. Would make things much simpler for everyone.

whstl 3y ago
Totally agree. There is a TC39 proposal for that: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- MrResearcher 3y ago
  That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme-ov-file#how-does-this-proposal-relate-to-typescript https://github.com/tc39/proposal-type-annotations?tab=readme...
  - whstl 3y ago
    Hmmm good catch. But on the other hand, it would be already fantastic to have at least a subset of TypeScript...
  - WorldMaker 3y ago
    It is more compatible than not and there are workarounds for most of the things that wouldn't work, many of which you shouldn't be using in Typescript today, have known workarounds (enums), and/or you probably have lint rules already warning against using (namespaces). (There are more details elsewhere in that proposal document outside of the direct linked FAQ question.)
    - whstl 3y ago
      Great point. It is 100% possible to survive without enums and namespaces. And in fact: I bet the Typescript team itself would deprecate them (or at least add extra checks to TS to avoid them) if the TC39 proposal above passed.

Jarred 3y ago

Bun transpiles Typescript to JavaScript before execution, removing types and doing some dead code elimination

crabmusket 3y ago

> or is it also compiling down to JS and executing that? This is the only way to execute TypeScript. That's how every tool that "executes" TypeScript works.

erhaetherth 3y ago
I don't buy it. That might be how every tool today works, but there's no reason V8 or whatever can't run TS the same way it runs JS.
- crabmusket 3y ago
  If it runs TS "the same way" it runs JS then how is that different to what I described? It would be a JS engine that strips the types before execution. There is a persistent fantastical hope that TS can somehow be a compiled language. It can't, not without breaking compatibility with JS. Until, of course, someone manages to compile JS - but at that point TS would be irrelevant. I say this as someone who loves TS and wouldn't want to be without it: TS is a fancy linter. JS defines the execution semantics of the language.