Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full es2020 compatibility by default #9062

Closed
4 tasks done
lgarron opened this issue Jul 13, 2022 · 15 comments · Fixed by #9063
Closed
4 tasks done

Full es2020 compatibility by default #9062

lgarron opened this issue Jul 13, 2022 · 15 comments · Fixed by #9063
Labels
enhancement New feature or request p3-significant High priority enhancement (priority)
Milestone

Comments

@lgarron
Copy link
Contributor

lgarron commented Jul 13, 2022

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 d416072 but I can't find out the reasoning why.
I was able to find some discussions and suggestions to update, such as #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

@ydcjeff
Copy link
Contributor

ydcjeff commented Jul 13, 2022

Vite 3 uses es2020 by default and it will be stable in a few days.

'es2020', // support import.meta.url

@bluwy
Copy link
Member

bluwy commented Jul 13, 2022

Yes Vite 2.9 doesn't target es2020 by default, but Vite 3 will.

@bluwy bluwy closed this as completed Jul 13, 2022
@lgarron
Copy link
Contributor Author

lgarron commented Jul 13, 2022

Vite 3 uses es2020 by default.

'es2020', // support import.meta.url

Thanks!

Unfortunately, using vite@v3.0.0-beta.10 it seems that ES2020 code isn't necessarily compatible:

✘ [ERROR] Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)

In fact, I'm no longer even able to get it to work using this:

// vite.config.js
export default {
  build: {
    target: "es2020",
  },
};

Are there still changes up in the air (such as changing safari13 to safari14) for Vite 3 that will allow full ES2020 to work out of the box in Vite 3, or at least big ints?

(In our case, the big int code is actually dynamically loaded, and will rarely be used. But that isn't much comfort help if the compiler doesn't allow it.)

lgarron added a commit to lgarron/vite that referenced this issue Jul 13, 2022
From vitejs#9062, it sounds like the goal is to support ES2020 by default. However, the browser list was set to `safari13`, which means that big ints (an ES2020 feature) produced an error by default.

This PR updates from `safari13` to `safari14` (released September 2020) to support that.

Thanks for any consideration of this change!
@bluwy
Copy link
Member

bluwy commented Jul 13, 2022

In fact, I'm no longer even able to get it to work using this:

This was a bug in Vite 2 where we used build.target for the optimizer (which was dev only and shouldn't inherit build configs). You should be able to get the same behaviour by setting optimizeDeps.esbuildOptions.target instead, which should work in both v2 and v3.

lgarron added a commit to lgarron/vite that referenced this issue Jul 13, 2022
@lgarron
Copy link
Contributor Author

lgarron commented Jul 18, 2022

As discussed in #9063 , es2020 is not fully supported by Vite 3.

If I want to ask for full es2020 compatibility out of the box, would it make more sense to ask to reopen this issue, or to file a new one?

@lgarron
Copy link
Contributor Author

lgarron commented Jul 18, 2022

In fact, I'm no longer even able to get it to work using this:

This was a bug in Vite 2 where we used build.target for the optimizer (which was dev only and shouldn't inherit build configs). You should be able to get the same behaviour by setting optimizeDeps.esbuildOptions.target instead, which should work in both v2 and v3.

FYI, I'm still seeing this issue in v3.0.1. 😕

lgarron added a commit to cubing/cubing.js that referenced this issue Jul 18, 2022
Even Vite 3 still seems to have issues: vitejs/vite#9062 (comment)
lgarron added a commit to cubing/cubing.js that referenced this issue Jul 18, 2022
Even Vite 3 still seems to have issues: vitejs/vite#9062 (comment)
@patak-dev
Copy link
Member

I think we could reopen this issue as a feature request for Vite 4. Maybe in a few months, we could already bump the modern browser's target to support BigInt.

@patak-dev patak-dev reopened this Jul 18, 2022
@patak-dev patak-dev added enhancement New feature or request p2-to-be-discussed Enhancement under consideration (priority) and removed enhancement: pending triage labels Jul 18, 2022
lgarron added a commit to cubing/cubing.js that referenced this issue Jul 18, 2022
Even Vite 3 still seems to have issues: vitejs/vite#9062 (comment)
lgarron added a commit to cubing/cubing.js that referenced this issue Jul 18, 2022
Even Vite 3 still seems to have issues: vitejs/vite#9062 (comment)
@lgarron lgarron changed the title es2020 target by default Full es2020 compatibility by default Jul 18, 2022
@lgarron
Copy link
Contributor Author

lgarron commented Aug 2, 2022

In fact, I'm no longer even able to get it to work using this:

This was a bug in Vite 2 where we used build.target for the optimizer (which was dev only and shouldn't inherit build configs). You should be able to get the same behaviour by setting optimizeDeps.esbuildOptions.target instead, which should work in both v2 and v3.

FYI, I'm still seeing this issue in v3.0.1. 😕

poke I'm still seeing this issue in Vite v3.0.4. Should I file a separate issue?

@bluwy
Copy link
Member

bluwy commented Aug 2, 2022

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.

@lgarron
Copy link
Contributor Author

lgarron commented Aug 2, 2022

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. 😕

@lgarron
Copy link
Contributor Author

lgarron commented Aug 2, 2022

Okay, ignoring the caching issues, it looks like there's definitely an issue with passing a root:

  • es2020 target works: npx vite with source in root folder.
  • es2020 target works: npx vite with source in subfolder.
  • es2020 target is ignored: npx vite subfolder with source in subfolder.

@yhoungdev
Copy link

this has saved my life, thanks a lot sir God bless you

@tobq
Copy link

tobq commented Sep 18, 2022

I'm using Vite 3.1.2
Is there any way to fix the error:
✘ [ERROR] Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)

without adding:

    optimizeDeps: {
        esbuildOptions: {target: "es2020"}
    },

to the vite config? Feels like a hack
Is this an issue regarding a lack of polyfill for browsers not supporting ES2020?

@bluwy bluwy added this to the 4.0 milestone Sep 18, 2022
@jscheid
Copy link

jscheid commented Sep 21, 2022

After upgrading from Vite 2 to 3.1.3 I was getting warnings like this, using custom HMR with a mostly vanilla config:

warning: "import.meta" is not available in the configured target environment ("es2019") and will be empty

None of the solutions offered above worked for me but this (apparently undocumented) option did:

// vite.config.js
export default {
  esbuild: {
    target: "es2020"
  },
};

I have no idea what I'm doing but HMR seems to work and warnings are gone ¯\_(ツ)_/¯
Hope this helps somebody.

It would be great if Vite maintainers could shed some more light.

@justin0mcateer
Copy link

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.

@bluwy bluwy added p3-significant High priority enhancement (priority) and removed p2-to-be-discussed Enhancement under consideration (priority) labels Nov 20, 2022
@bluwy bluwy linked a pull request Nov 20, 2022 that will close this issue
9 tasks
@github-actions github-actions bot locked and limited conversation to collaborators Dec 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request p3-significant High priority enhancement (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants