Wrong esbuild target when using `vite dev`

[newcat]

Describe the bug

When setting a build target in the config using either build.target or esbuild.target, this only applies to vite build. So far, this is expected, since #10207 automatically sets the esbuild target to esnext when using vite dev. However, when I import a library that requires the target to be set to esnext (bson for example) and try running vite dev I get this error message:

[ERROR] Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)

Running vite build works fine. So I am wondering, why the target environment during vite dev is set to the default target instead of esnext.

Reproduction

https://stackblitz.com/edit/vitejs-vite-rfowdk?file=main.js

Steps to reproduce

• Running vite build succeeds
• Running vite dev fails

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.20.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm
    pnpm: 8.6.3 - /usr/local/bin/pnpm
  npmPackages:
    vite: ^4.4.0 => 4.4.2

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[bolt-new-by-stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitejs-vite-rfowdk (Open reproduction)

[hai-x]

Glad to answer your questions.

Vite use esbuild to pre-bundle dependencies in node_modules. For pre-bundle stage, optimizeDeps.esbuildOptions is used as transform api's parameter. You can try it.

vite/packages/vite/src/node/optimizer/index.ts

Line 809 in c8a741a

...esbuildOptions,

I just tried it, and it work.
https://github.com/haijie-x/vite-issues/tree/master/esbuild-target

Not sure if I misunderstood you, but I hope this can help you.

[treardon17]

I am also having this issue. I'm working on an Adobe plugin and using vite to build/develop. Adobe's current environment is using chrome version 88, so having the default build output for dev being set to esnext does not work in this case, as there are many features in esnext that do not work in chrome 88. Changing this line from esnext to es2020 does resolve the problem.

I understand there is supposed to be a way to override this behavior using optimizeDeps.esbuildOptions, however it does not appear to work for me if I set optimizeDeps.esbuildOptions.target to es2020. Seems like this should default to the target defined in the tsconfig file rather than needing to override this in the esbuild options?

[treardon17]

However, it's also worth noting that I'm not having this issue on version 4.3.9, but I am having this issue on 4.4.0 and above. It appears the line I referenced above is present in both versions, so it is likely not the root cause of the issue.

[bluwy]

Changing this line from esnext to es2020 does resolve the problem.

The configuration for that line is through the esbuild.target config for your source code. The optimizeDeps.esbuildOptions config is used to configure optimizing deps code.

[treardon17]

@bluwy looks like that works, thank you! I am curious though... shouldn't the build be picking up my tsconfig target? it seems a little odd and unfortunate to need to define the build target in multiple places.

[newcat]

So as far as I understand, this is how the target is determined for the different parts:

Command	App	Deps
vite dev	set to esnext automatically	optimizeDeps.esbuildOptions.target
vite build	build.target	build.target

I find this quite confusing, honestly. IMO everything should be affected by build.target. Maybe it could be overridden by optimizeDeps.esbuildOptions.target, but the default value should be the one from build.target and not the global default. Is there any specific reason for how it's implemented currently?

[bluwy]

@newcat build.target should only affect the build as its name suggest. For dev, the goal is to only transpile to normal JS as serve it as-is. E.g. if you're writing .js file with bleeding-edge features, Vite isn't going to run that file through esbuild either. So that PR was keeping it in line between .ts and .js. (But I'd admit that I initially didn't plan for esnext to always override in that PR, I figured it was more of a fallback if compilerOptions.target is not specified.)

However, it's also worth noting that I'm not having this issue on version 4.3.9, but I am having this issue on 4.4.0 and above.

@treardon17 I'm currently also tracking this behaviour in #13863, but I haven't yet figure out where is causing this issue.

---

I agree that it would be better to have a single place to configure target instead though, but I'm not sure how that looks like as it conflicts with Vite's transpiling setup. The configs in dev are intentionally "more verbose" due to the reasons above.

[treardon17]

@bluwy I may be misunderstanding something, but I'm not sure if separating the targets for build vs dev is a good default behavior. I could see it being a useful opt-in behavior if it's explicitly set. With the exception of minification, I expect (or hope) my code will have the same output in both scenarios because debugging/fixing something is much more difficult if it is built for a different environment.

[bluwy]

That's how Vite works fundamentally (even before I started maintaining it). Dev and build are two separate paths, and while we try to keep things consistent between them, dev has kept it's philosophy of serving things as-is without too many work that slow things down.

Maybe I could see dependency prebundling falling back to build.target instead of Vite's hardcoded set of targets though. They're making a build after-all, and if we're able to nail prebundling in builds too, the change makes more sense.

---

I took another look in the issue and it seems to not be a regression like I thought. It is working as expected and only needs the right optimizeDeps.esbuildOptions.target configuration. I think we can document this better at https://vitejs.dev/guide/#browser-support