Full `es2020` compatibility by default

Description

I help maintain a library that requires es2020 syntax (e.g. import.meta.url and bignum support). We’d love to recommend Vite as a bundler that works “out of the box” with batteries included, but this doesn’t quite work because the default Vite target is es2019. Our goal is to make it as easy as possible to use our library with little programming experience, and we would really like to suggest a bundler that can be run directly without configuring anything.

The main README.md history says that es2020 used to be the target — back in 2020, actually!. This was revised in https://github.com/vitejs/vite/commit/d4160726501779417ef19f05cc621bf1a0302097 but I can’t find out the reasoning why. I was able to find some discussions and suggestions to update, such as https://github.com/vitejs/vite/pull/7279 , but they don’t seem to shed any light on this.

Now that it’s 2022 and ES2020 is well supported in browsers, would it be possible to revise the default? If not, could I ask for the reasoning for the current default, and what compatibility threshold might allow it to be revised in the future?

Thanks!

Suggested solution

Change the default target to es2020.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that request the same feature to avoid creating a duplicate.

[lgarron]

Did you set optimizeDeps.esbuildOptions.target: 'es2020'? Or I think optimizeDeps.esbuildOptions.supported: { bigint: true } works too. We could bump up the defaults in Vite 4.

Yes, I’ve tried all three configs, separately and at the same time:

export default {
  build: { target: "es2020" },
  optimizeDeps: {
    esbuildOptions: { target: "es2020", supported: { bigint: true } },
  },
};

From playing around with this for an hour, it seems that Vite 3 has either undocumented behaviour and/or caching bugs, along with potentially different behaviour depending on whether a folder is passed on the commandline (compared to defaulting to the current folder). This all makes it exceedingly difficult to tell if I’m debugging properly. 😕

[justin0mcateer]

It’s probably my just my ignorance, but I don’t understand why it is necessary (or makes any sense) to have to set the build target it five or six places.