[jpgvm]

Yeah definitely. Typescript is passable, even has some decently cool stuff like discriminating unions which would be nice to have more widespread. The tooling however is just awful.

I'm trying to make it palatable with Bazel + rules_js/rules_ts and pnpm but even so still end up needing Babel and Webpack because browsers are a thing. This stack does make the build times somewhat more reasonable and actually manages to avoid too much wasted work locally/CI but boy does it take a lot of work to get done.

The time I'm investing in making a Typescript monorepo viable will pay off but only when compared to not implementing my changes and staying with TS, the comparison to simply not using the stack and using something better to solve our non-Typescript specific business problems would rather lopsided.

[TobyTheDog123]

My usual project stack is React Native (+React Native Web) to cover iOS/Android/Windows/Mac/Web all in one repo, with serverless functions (Workers/C@E/etc) on the API side in another, and with shared types between the two as a third.

However I have different business goals where I can actually take some time to choose a non-TS stack...

... but unfortunately with those kind of goals/restrictions the choices aren't really there, afaik.

On the client-side, you have Flutter, which is cool enough (No JS, everything in a canvas), but I'm not Dart's biggest fan, and there's no Dart WASM target yet to be able to write in one language for both (and share types).

On the server-side, most cloud companies only support Javascript + Rust + WASM, and WASM just isn't mature enough yet where it's not a total pain to work with (I think it'll get there at some point though)

So I'm left pretty much where you are, my last and only hope is a Typescript monorepo.