privatenumber / tsx

⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js
https://tsx.is
MIT License
9.77k stars 154 forks source link

Request to extend `esbuild` semver range #647

Closed benmccann closed 1 month ago

benmccann commented 2 months ago

Acknowledgements

Minimal reproduction URL

https://github.com/privatenumber/tsx/blob/157c3ec6bcf0b0a5e387080576404c00f7fd662f/package.json#L80

Problem & expected behavior (under 200 words)

esbuild is a somewhat heavy library with lots of dependencies. I already have another version of esbuild pulled in by Vite. Is there any chance you'd accept a PR to extend the range of allowed versions so that I don't end up with multiple versions?

E.g. like this: https://github.com/antfu-collective/importx/blob/08d68f31b4c4e927d59c99e0adb488aa7be9df54/package.json#L55

Bugs are expected to be fixed by those affected by it

Compensating engineering work will speed up resolution and support the project

privatenumber commented 1 month ago

Thanks for the issue.

Regarding the impact of the problem, I think this is low priority as users can address it on their end through dependency overrides. And most tsx users aren't concerned with dependency de-duplication, as the target audience is broad, extending to beginners.

While dependency size is a valid concern in the npm ecosystem, this issue not unique to tsx as many tools leverage esbuild (even if tsx addresses it, you'll still encounter it from another package). Most users can mitigate this by using pnpm, which minimizes disk usage at a system level. But if you're particularly concerned about esbuild's size, addressing it with esbuild level would likely yield bigger wins. For instance, perhaps splitting the Transform API from the Build API could reduce its size, making a more substantial impact across the ecosystem.

As for the request to extend esbuild's version range in tsx, I'm not keen on the maintenance work involved, including adding/removing versions and reviewing PRs. It also raises process questions: when to add/remove versions, what to do if tsx relies on a new esbuild feature (is it a breaking change to drop old esbuild verisons?), or how to handle compatibility changes (do I need to test old esbuild versions?). I don't mind doing meaningful work for free, but the tradeoff between the maintenance work vs the wins here are questionable.

For anyone bothered by esbuild's size, I would recommend using overrides and filing a request with esbuild.

privatenumber commented 1 month ago

Also, the Issues tab in tsx is reserved for bugs, and there is no bug here I'll be closing & locking this.

But please feel free to move this discussion to the sponsors-only repo. Happy to continue the conversation there.