Could you provide why not? I have a utility library (Project A) and whilst messing around with TurboRepo, I noticed I could point to the source files in my package. I haven't progressed down that route, but something about it seemed nice.
So in other words, if Project B depends on Project A, either I could build Project A and then build Project B or I could just build Project B (which consumes Project A as a typescript package).
Kinda confusingly written but I would love to know why that is an issue.
One thing that comes to mind is different TypeScript versions.
JS has ES6 and ES2020 etc and that’s enough to deal with, Typescript is younger and has been moving faster, compatibility might be difficult around the edges.
Longer term I agree with you though, I’d much rather see TS source than JS plus types when I’m looking at the source code of a module.
I don’t know why you’re being downvoted, my experience has been that minor version TS releases usually create a cascade of hundreds of type check failures even though the syntax itself is backwards-compatible.
It would be impossible for a project pulling TS sources directly to achieve stability (or even compile all dependencies with a single version of TypeScript in the first place).
In Deno with JSR, only the public API gets used for type checking because publishing enforces that the public API can be determined without type inference. So it's similar to declaration files (d.ts files) and you wouldn't see errors that occur at the non-declaration level unless someone explicitly opted out of those publishing checks (which is heavily discouraged).
I tried to do exactly what you say last week but I couldn't get it to work. The turborepo documentation seems to indicate its possible with the whole concept of "internal packages" but it all depends on the compilation step of Project B being configured to compile and bundle workspace dependencies, and a simple "tsc" wasn't doing it for me regardless of the different tsconfig settings I tried.
I made a private repo who's package JSON was `private: true`, `type: module` and `main: src/index.ts` and `module: src/index.ts`. I didn't progress down that route as stated, but I was able to consume that package. Maybe none of what I said here mattered in which case the only other thing that may make a difference was that I was using pnpm for the first time with workspaces.
The only downside that I see is that the runtime needs to be able to compile older versions of TS with all the quirks of that specific TS version, so likely it would need to ship multiple TS compilers.
If only the ECMA Typo proposal would finally be implemented, we wouldn't have all these issues.
