Can also be reproduced with this chromium version (has devtools; grab chrome-win.zip):
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/683419/

It's worth noting that I was having issues with transpilation working in dev mode at all, for which I had to explicitly add esbuild.target option like so, in addition to existing build.target:

export default defineConfig({
    // [...]
    plugins: [vue()],
    build: {
        target: ["chrome102", "safari13"],
    },
    esbuild: {
        target: ["chrome102", "safari13"]
    },
    // [...]
});

Because of that I was not sure if issue belongs to vite or this plugin here. These issues might even potentially be unrelated, I mention the above thing just now, because I forgot at that time I even did this, assuming it just made things work.

vite-plugin-vue always transpiles Vue code into esnext, not follows dev server config.

I think you should use the latest browser for developing,
But if there are special cases, this is also possible to be a bug.

I think you should use the latest browser for developing,
But if there are special cases, this is also possible to be a bug.

My case is a little bit special, because I develop for an embedded browser for a video game, which is a product based on a fixed version of WebKit which they rebase on top of latest version with some considerate delay (current version is based on mid-2019 WebKit, they plan to update to newer one within a couple of months).

With that + the fact this kind of browser has custom JavaScript bindings for communication with the game engine, it'd be hard to test with an outside browser, as even developing mocks would not give the exact same experience behavior. And the thing is, it basically fully works, until it encounters some ES2020+ syntax like here.

vite-plugin-vue always transpiles Vue code into esnext, not follows dev server config.

I see, would it be possible to consider changing it? I'm not exactly sure what's the relationship here between the Vue plugin and Vite, but I know setting esbuild.target in Vite config causes it to transpile .ts files in dev server mode, and that seems to work 100% fine. After all ESBuild is pretty fast, and theoretically matching the target option as long as it's post-ES6 shouldn't really have any side effects, right? Maybe the plugin could try to inherit that target option or at least make it manually configurable for the user?

Or perhaps it's a Vite bug that it transpiles .ts files directly there, but not output of plugins?

Vite transpiles .ts code to esbuild.target, but Vue Plugin does not.

Assume esbuild target is es6, when dev for IE11 (only ES6).

Then the code ({ n: 1 })?.n.

• runs at main.ts, it is transpiled to es6 by Vite.

• error occurs at HelloWorld.vue, it is also transpiled, but to esnext by Vue Plugin.

If this is seem like a bug. Vue Plugin should follow Vite config.

Vue Plugin use import.meta for HMR. That feature is available >= ES2020.

If retrieved esbuild target from Vite is < ES2020. Plugin should show warning even error message.

I can't provide any approach for your case excepting take patch. It is hard-coded.

@sapphi-red Sorry for pinging. Would you see it as a bug?

When esbuild.target is ES2020+, I think this is a "p3-minor-bug" and "regression". I think we should use esbuild.target if it's defined.

But when esbuild.target is ES2020<, it's not a "regression" because it didn't work in past. IMO it's a "won't fix". Vite heavily relies on import.meta and won't work without that. Maybe you could workaround with a custom plugin.

FYI this part was set by vitejs/vite#10207 to avoid transpiling import.meta into import_meta that breaks HMR.

In my case it seems the browser turns out to not be actually ES2020< (Safari 13), as import.meta is supported (since Safari 11.1), thankfully.

I can confirm that manually editing vue plugin's .js file under node_modules to change esnext to safari13 fixes my issue and everything works 100% properly then.

In such case I think it would be reasonable to just use the esbuild.target setting directly if it's defined. If too old of a target there would break Vite's dev server itself due to lack of import.meta support, then I think it's not a concern of this plugin itself, as the whole HMR system would already be broken in the first place, so nothing would work. So perhaps Vite should have some warning for too old setting there, but the possibility to transpile between that minimum HMR target and latest proved very useful to me, so it would be cool to keep it there, given it works just fine and is optional (as in my use-case I can't really use any other browser than my exact frozen target version).

@p0358 same issue and modify target inside node_modules/vite-plugin-vue fix my problem too. I also agree that specifying a too low target which breaks the bundle is not the concern of this lib. It is user's concern specifying target in the config.esbuild. vite-plugin-vue should respect the target in esbuild regradless of the risk that may break the bundling.

As seen above, browser starting from 2018 already support import.meta, which is much earlier than the release of es2020.