I like TypeScript and we have a full-stack system on TypeScript but it's not perfect. Configuring TypeScript for monorepos is a nightmare. Having to make sense of it with internal packages under a pnpm monorepo requires lots of manual tsconfig.json work to make all of the paths work with each other. And our production toolchain was basically unmaintainable until the excellent tsx package became available.
It's also crazy slow. We're having issues with Zod where it slows down our TypeScript language server performance significantly, so as a result we've had to introduce project references and disable project reference redirects.
All-in-all, there's plenty of work to be done to make TypeScript better. Especially in monorepos, and especially in making it performant.
Zod is known to be slow. Typebox for example is much faster - not saying you should switch, but that it's not a Typescript issue or something that needs to be addressed by Typescript.
Your monorepo issues sound like you didn't use the same config in all the packages? If that's the case, enforcing the same config and coding standards would be the first thing I would fix. Again, not a Typescript issue. Or did you use ts-node before tsx? Yeah, tsx is much more robust. It just works.
We’re considering Typebox but it’s a big lift and the author of Typebox, while responsive in GitHub, doesn’t seem interested in improving interoperability and documentation regarding usage with tRPC.
> I like TypeScript and we have a full-stack system on TypeScript but it's not perfect. Configuring TypeScript for monorepos is a nightmare.
It isn't TypeScript that needs to support your particular set of tooling and library choices, but the other way round. We have a mid-sized monorepo (multiple apps, many services) which is mostly typescript. It works alright with a boring npm workspaces based configuration.
Zod is recommended by most modern type safe packages. Also this is not the first time we’ve run into TS performance issues. MUI also suffers from poor TS performance.
I agree with your assessment re: library choices in theory but it suck to run into these DX problems that you wouldn’t normally run into with other languages, like Go for example.
Saying typescript is slow because zod is slow is like saying c++ is slow, because javascript is slow. Not to say that typescript is quick in any way (how could it be, as something written in javascript). But letting typescript execute code to infer types in a large scale application seems like a self inflicted issue.
What do you mean by that? I don't think Zod is doing anything special as far as the TS type system goes, although its types are necessarily complex to make its "magic" work. But it's not executing code to infer the types
But TypeScript IS slow. It just so happens that the issue is currently with Zod but JavaScript in general has always been less performant than other lower level languages. This is why JavaScript tooling is all built in other languages.
It's also crazy slow. We're having issues with Zod where it slows down our TypeScript language server performance significantly, so as a result we've had to introduce project references and disable project reference redirects.
All-in-all, there's plenty of work to be done to make TypeScript better. Especially in monorepos, and especially in making it performant.