[Feature] yarn run and yarn dlx for typescript source files

[balupton]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

I was quite impressed with tink's support for typescript, but as tink seems abandoned now, my focus is now looking at yarn.

The dream would be for me to just publish typescript source then have yarn be able to run it, so that I can do away with all the developer overheads of compilation.

The the user can use yarn to run their own app, and pika cdn for their web apps, and we don't have to worry.

Describe the solution you'd like

Yarn supports typescript source files out of the box.

Describe the drawbacks of your solution

Non-typescript users need to use yarn or pika or webpack or tsx-node, or just accept using typescript.

Describe alternatives you've considered

Every package author deals with typescript compilation complexity and project formatting.

Or a cloud service is developed which listens for github tags on opted repos then does the compilation and dep handling and project structure and changelog and npm publishing.

Or tink is rebooted.

Or we all move to deno.

Or microsoft forks node to support typescript natively and transparently.

Or everyone uses ts-node.

Additional context

N/a

[arcanis]

I'm not a fan of this for various reasons:

• I'm a strong believer of "one tool that solves one issue very well". Yarn is a package manager, and although we are becoming a bit more generalist by being a project manager, we're still a long way from a language runtime.

• I'm not convinced it's healthy for the ecosystem to provide this kind of favouritism. Why TypeScript and not Coffeescript? You could argue that one is bigger than the other, but once upon a time it wasn't the case. Would TypeScript have succeeded if its competitors had benefited from such advantages¹? It goes the other way around: what if TypeScript suddenly become very bad? Is the ecosystem locked?

• It would be impossible to satisfy everyone; half the ecosystem uses TypeScript, but that also mean that half the ecosystem doesn't. Our bundle would then become twice as big as it should be for something that half the ecosystem wouldn't use. And it's not like for VSCode where you get the choice of which editor you want to use - in the case of your package manager, you most certainly will want to use Yarn even if you don't use TypeScript.

• There are technical problematics behind this. Which version of TypeScript should we ship? Should the TS teams sync with us to keep it in sync? What if we want to have a slower release cycle than them? If we don't ship a TypeScript version, would this "native support" be much better than just using ts-node?

• It's quite likely we could figure out a way to integrate this capability as a plugin (for example by injecting ts-node as the node binary in the env when spawning a script, which is already possible), which I would be more favorable to than shipping it by default. It could even be part of the official plugin-typescript.

Imo the current state of business (running tsc to generate JS + type definitions) is an acceptable workflow. It's a bit more work for project authors, but it guarantees that all developers, regardless of their language, get to share the same code with progressive enhancement. The one thing I'd appreciate would be for TypeScript to have a native support for PnP, but that's really on them now (microsoft/TypeScript#28289).

_{¹ You can somewhat ironically draw a parallel between two famous package managers, one being shipped with Node by default but not the other. Would as many people use the former if it didn't have such a privilege?}

[balupton]

Thank you for the quick and informative explanation. Happy to have this go wherever you wish, be it closing or whatever.

[arcanis]

Going to close for now, but maybe we'll have a plugin for this in the future