Comment by m3h

1 day ago

The speed up numbers based on their testing:

    Codebase    | TypeScript 6 | TypeScript 7 | Speedup
    ------------|--------------|--------------|--------
    vscode      | 125.7s       | 10.6s        | 11.9x
    sentry      | 139.8s       | 15.7s        | 8.9x
    bluesky     | 24.3s        | 2.8s         | 8.7x
    playwright  | 12.8s        | 1.47s        | 8.7x
    tldraw      | 11.2s        | 1.46s        | 7.7x

Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun).

Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?

32 comments

m3h

Reply
DanRosenwasser  1 day ago

> How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase?

esbuild doesn't rely on TypeScript at all, so there's no issue there.

With tsdown on the other hand, it depends on if you use --isolatedDeclarations. If not, you can install TypeScript 6 side-by-side (instructions for this are on the blog)

hackerbrother  1 day ago

Do you think Bun's migration was irresponsible?

  • ricardobeat  1 day ago

    Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear.

    Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.

    • spartanatreyu  1 day ago

      > this TS migration started long before AI was able to help

      Yes, but that doesn't mean it wasn't also "helped" along by AI.

      See:

      1. https://github.com/microsoft/typescript-go/pull/1387

      2. https://github.com/microsoft/typescript-go/pull/2978

      3. https://github.com/microsoft/typescript-go/pull/1138

      4. etc...

      Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.

      ---

      The initial port was automated, then devs got in there, then LLMs got in there.

    • docmars  1 day ago

      Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place.

      It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way.

      Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.

      10 replies →

  • mindwok  1 day ago

    I don't think irresponsible is the right word, but it has drastically reduced Bun's appeal. All the tools we use have a brand to them, and Bun basically changed their brand overnight to "reckless" in my eyes.

    • jitl  1 day ago

      bun has never been fit for production, at least not for load bearing business apps. it’s been haunted by segfault bug reports since the early days, and i personally hit at least one a week when im doing lots of bun stuff. im excited for bun with less segfaults

      1 reply →

  • bastawhiz  1 day ago

    It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.

paulddraper  1 day ago

"How does this affect downstream tools"

> It’s worth calling out that workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7. This is mainly because TypeScript 7 does not yet expose a stable programmatic API, and so tools (such as Volar) which embed TypeScript into their own compilers and language services can only currently rely on TypeScript 6.0. We expect this to be a point-in-time issue, as we are committed to providing a solution here. We will be actively working with the maintainers of these projects to ensure TypeScript 7 supports these workflows.