feat: esbuild 0.17

[sapphi-red]

Description

This PR updates esbuild to 0.17.5 from 0.16.14. v0.17.0 has some breaking changes. The breaking changes are:

• Move everything related to incremental builds to a new context API
  • This does not affect most users. If a user is using a plugin that uses build.esbuild.serve/build.esbuild.build + rebuild, it will break.

    const examplePlugin = {
      name: 'example',
      setup(build) {
        build.esbuild.serve() // something like this
      }
    }
• Incremental builds now write out build results differently
  • This does not affect users as we don't use incremental: true. Also we don't expect users to set optimizeDeps.esbuildOptions.incremental: true.
• The onRebuild watch mode callback was removed
  • Since we don't expect users to set optimizeDeps.esbuildOptions.watch, I think we can ignore this one.

FYI type definition diff: evanw/esbuild@v0.16.17...v0.17.0#diff-53664fbdfc62af3b722184289b51ff956243fc8f7e81fb9d0548219307587f7c

Because of the first change, it's technically a breaking change. That said, I guess most plugins doesn't use these and the benefit of bumping the version in minor is larger than little breakage.

Also upgrading esbuild will unlock context.dispose API that will make #11243 straight forward.

close #11704

Additional context

---

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.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• 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).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

I think this make sense for the next minor too. The first case is pretty strange and doesn't fit optimizeDeps that I think it's safe to bump this.

[sapphi-red]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
astro	✅ success
histoire	✅ success
iles	✅ success
ladle	✅ success
laravel	✅ success
marko	✅ success
nuxt-framework	✅ success
previewjs	✅ success
qwik	✅ success
rakkas	✅ success
sveltekit	✅ success
vite-plugin-ssr	✅ success
vite-plugin-react	✅ success
vite-plugin-react-pages	✅ success
vite-plugin-react-swc	✅ success
vite-plugin-svelte	✅ success
vite-plugin-vue	✅ success
vite-setup-catalogue	❌ failure
vitepress	✅ success
vitest	✅ success
windicss	✅ success

[sapphi-red]

vite-setup-catalogue is failing with main branch and I guess it's a problem on vite-setup-catalogue side.

[patak-dev]

I also think we should upgrade on the next minor. Breaking changes in esbuild and rollup in our minors have also happened in the past. Maybe in Vite 5 we should formalize that in Vite minors, we may upgrade esbuild and rollup and users should pin Vite to the current minor if they depend on esbuild plugins or rollup types (that we saw breaking in minors). Related: clarify in Vite 5 a policy for Node.js minors.