Closed LinusU closed 1 month ago
Thank you for the PR, but I typically don't accept esbuild upgrade requests unless they address a specific bug or issue. In this case, esbuild was released with a breaking change label, which poses unnecessary risk to tsx users without clear benefit.
If your main motivation is to standardize on a single version of esbuild, I recommend using a package manager override to achieve that in your project.
Since tsx is designed to be user-friendly, the average user won't be concerned with dependency de-duplication, and we want to avoid causing potential disruptions unless absolutely necessary.
Makes sense 👍
I'll look into using overrides instead!
It would be neat if tsx used peer-dependencies to let users bring their own version of esbuild while at the same time indicating which versions are compatible. But as you explained, that probably doesn't vibe with the intention of this project either 😅
@privatenumber So is that issue #647 possible to be resolved with the goals of tsx (user-friendly)? There should be a way to avoid duplication of dependencies versions.
Would you accept a PR which change the semver to esbuild from:
"esbuild": "~0.23.0",
to
"esbuild": "~0.23.0 || ~0.24.0",
or like there: https://github.com/antfu-collective/importx/blob/08d68f31b4c4e927d59c99e0adb488aa7be9df54/package.json#L55
"esbuild": "^0.20.2 || ^0.21.0 || ^0.22.0 || ^0.23.0",
This bumps esbuild to version 0.24.0.
I wanted this since I'm affected by https://github.com/evanw/esbuild/issues/3887, which prints a lot of warnings when I build with 0.23.0. I also want to use the exact same version of esbuild when running locally, and building for deployment.
Thanks for an amazing tool! 🙏