fix: upgrade esbuild to 0.20.x

[43081j]

Description

Upgrades esbuild to 0.20.x

Quite a few of our peers have already upgraded, so it is leading to us having a fair amount of duplicate installs of esbuild in our dependency tree. would be nice to bump the version here so we can de-dupe

Let me know if there's any reason you think we can't do this yet

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines, especially the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Update the corresponding documentation if needed.
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sapphi-red]

I didn't make a PR to bump esbuild because we don't bump esbuild minors in a patch and Vite 4.1.0 was already kinda RC phase
when esbuild 0.20 was released. But it seems there's no breaking change that affects Vite. I think we can release this PR in a patch.

[43081j]

that makes sense, does seem like we should be ok per the changelog at least

thanks for taking a look 👍

[patak-dev]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 9e7e1a6: Open

suite	result	latest scheduled
nx	❌ failure	❌ failure
vite-plugin-react-pages	✅ success	❌ failure

✅ analogjs, astro, histoire, ladle, laravel, marko, nuxt, previewjs, qwik, rakkas, sveltekit, unocss, vike, vite-plugin-pwa, vite-plugin-react, vite-plugin-react-swc, vite-plugin-svelte, vite-plugin-vue, vite-setup-catalogue, vitepress, vitest

[bluwy]

Hmm I feel like we should have waited this for the next minor since this breaking change feels a bit risky:

Reorder implicit file extensions within node_modules

[patak-dev]

I'm fine with reverting it and wait 👍

[sapphi-red]

The reorder behavior already existed in 0.18. The reorder change in 0.20 small IMO.

Specifically the default implicit file extension order is .tsx,.ts,.jsx,.js,.css,.json which used to become .jsx,.js,.css,.json,.tsx,.ts in node_modules directories. With this release it will now become .jsx,.js,.tsx,.ts,.css,.json instead.

[bluwy]

I think re-ordering extensions is a big deal though, it changed again in 0.20 which isn't the same as 0.18. This affects especially for internal projects where packages are published raw, and projects where they set esbuildOptions.resolveExtensions and now js/ts work differently. A patch usually involves bug fixes / improvements, but this seems like a bigger behaviour change.

[sapphi-red]

Just in case, the change in 0.20 doesn't swap the order of .js, .ts. The change affects when you have both a.css and a.js and you import it with import './a' (pre-0.20: resolves to a.css, 0.20+: resolves to a.js).
But yeah, I agree that it's not that small. Let's revert it and wait for 4.2.

[43081j]

in terms of getting this done in 4.2, when/how do we re-merge it?

happy to remember to push it again or rework the PR if i understand where we want it

[sapphi-red]

Thank you. But I'll create the reapply PR when the revert PR is merged, since that should be possible with a single button on GitHub. I'll put it in the milestone so that we don't forget to merge it in 4.2, too.

[bluwy]

Thanks for reverting this Sapphi 🙏