Hacker News Reader

Comment by pier25 | Hacker News Reader

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

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?

View on HN

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.

Totally agree.

There is a TC39 proposal for that: https://github.com/tc39/proposal-type-annotations

That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme...

Hmmm good catch.

But on the other hand, it would be already fantastic to have at least a subset of TypeScript...

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.)

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.

Yeah, if this type annotations proposal gets to higher stages I expect the associated ES target to get far more strict warnings/errors on those features.

Though I'd suggest that the Typescript team also doesn't seem to be waiting on that to try to deprecate them, either. They've made it somewhat clear that the only reason enums and namespaces survive is a commitment to deep backward compatibility (both go all the way back to 1.0) and are neither features that they would add today (without waiting on TC-39 proposals for those features in JS first). As an interesting side note: up until very recent versions the Typescript code base itself was one the biggest users of both enums and namespaces. (They managed to finally do a lot of namespace removal in the very recent ESM rewrite. I haven't checked where they are at in enum removal.) It is always fascinating to me how important backward compatibility can be when you bootstrap your compiler in its own language.

It's not just stripping types: enums have a runtime representation that needs to be generated.

Why would doing work at run time that can be done at build time be a good idea? I have a CI, I'd rather have it so the build work rather than delegating that to my production servers.

(note that you still have to tsc everything anyway in the CI to check the types, so when you ship TS files to production your CI does the hard work, but then doesn't finish the easy part it so your prod server has to do it? Why?)

You can also ask why every node server traverses the file system to load dependencies at runtime instead of build time. Packaging your server with bun build can be the answer to both.

"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

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.

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?

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.

So "type-checking is run". Could it not be run by Bun automatically?

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.

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.

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.

> 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.

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.

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.

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

Reply on news.ycombinator.com