@vitejs/plugin-legacy: polyfills vs modernPolyfills

[edamascus]

I am using Vite with CSR React app. I updated the app's dependencies recently to their latest version and everything is working well in development and production in modern browsers.

One of the app's dependencies is using Object.hasOwn and this has caused the following error to appear to some users which are using legacy browsers: Object.hasOwn is not a function.

In order to fix the issue I added the following setting to @vitejs/plugin-legacy:

plugins: [
  react(),
  legacy({
    targets: ['defaults', 'not IE 11'],
    polyfills: ['es/object/has-own'],
  }),
],

However, this did not fix the issue and the error remained.

I updated the legacy plugin settings as follows:

plugins: [
  react(),
  legacy({
    targets: ['defaults', 'not IE 11'],
    polyfills: ['es/object/has-own'],
    modernPolyfills: ['es/object/has-own'],
  }),
],

With this setting, the error seems to have been fixed in legacy browsers.

According to the official documentation, the polyfills setting is supposed to add the required Object.hasOwn polyfill when the app is loaded in legacy browsers. What I don't understand is why this did not work until I added the modernPolyfills setting.

What is the difference between polyfills and modernPolyfills in this case?

[mprevdelta]

Appreciate this discussion. Saved our butts with your workaround...

[bmakan]

I find the @vitejs/plugin-legacy very confusing to use. All I needed was to add polyfill for the new Set methods. But this plugin generates two kind of files (chunks): legacy and modern.

Legacy seems to intended for very old browsers which don't support ESM nativelly. But I found it also transpiled all the code to ancient mode. No const, no arrow functions, etc.

Modern code seems to be intended for modern browsers with majority of the modern features supported (mainly ESM native support).

But the default targets for legacy and modern chunks is as follows:

• legacy: ['last 2 versions and not dead, > 0.3%, Firefox ESR']
• modern: ['edge>=79, firefox>=67, chrome>=64, safari>=12, chromeAndroid>=64, iOS>=12']

Why are we generating legacy code for modern browsers and modern code for legacy browsers?

Anyway, to finally get what I wanted (create polyfill for the modern browsers), I set the config as follows:

export default defineConfig(({ mode }) => ({
    build: {
        target: 'esnext',
    },
    plugins: [
        legacy({
            modernTargets: ['defaults'],
            modernPolyfills: true,
            renderLegacyChunks: false,
        }),
    ],
}));

Without setting build.target, I got an error:

x Build failed in 21.28s
error during build:
[vite:esbuild-transpile] Transform failed with 1 error:
assets/index-!~{001}~.js:21091:29: ERROR: Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)

Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)
21089|  };
21090|  
21091|  const { inflate, deflate } = await __vitePreload(async () => { const { inflate, deflate } = await import('./pako.esm-!~{002}~.js');return { inflate, deflate }},true?__VITE_PRELOAD__:void 0);
   |                               ^
21092|  const compress = (text) => btoa(String.fromCharCode(...deflate(text)));
21093|  const decompress = (comressed) => String.fromCharCode(...inflate(Uint8Array.from(atob(comressed), (c) => c.charCodeAt(0))));

    at failureErrorWithLog (/home/bmakan/ws/feature-tracking-system/src/client/node_modules/esbuild/lib/main.js:1472:15)
    at /home/bmakan/ws/feature-tracking-system/src/client/node_modules/esbuild/lib/main.js:755:50
    at responseCallbacks.<computed> (/home/bmakan/ws/feature-tracking-system/src/client/node_modules/esbuild/lib/main.js:622:9)
    at handleIncomingPacket (/home/bmakan/ws/feature-tracking-system/src/client/node_modules/esbuild/lib/main.js:677:12)
    at Socket.readFromStdout (/home/bmakan/ws/feature-tracking-system/src/client/node_modules/esbuild/lib/main.js:600:7)
    at Socket.emit (node:events:518:28)
    at addChunk (node:internal/streams/readable:559:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)
    at Readable.push (node:internal/streams/readable:390:5)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)

I don't have such targets anywhere. Bug?
Is it trying to create legacy chunks? Why? I clearly stated I don't want them. Bug?

At the very least, I think the documentation needs to be made more clear on what the plugin does and how to achieve common goals. There should be a straightforward way to achieve: "Add polyfills for anything missing. My targets are ." By setting the targets, we're also transforming the code, which is not always necessary (depends on target).

[zangbianxuegu]

Hi, it seems that @vitejs/plugin-legacy determines the target for modern chunks independently of Vite’s build.target.

In your case, modernTargets is set to 'defaults', which resolves to ['es2020', 'edge88', 'firefox78', 'chrome87', 'safari14']. This is similar to Vite’s default build.target: 'modules'. Although the default value of modernTargets is ['edge>=79, firefox>=67, chrome>=64, safari>=12, chromeAndroid>=64, iOS>=12'], If it's not set, plugin-legacy will fallback to the default value..

However, Top-level await cannot be transpiled, and since the resolved modernTargets includes browsers that do not fully support Top-level await, this leads to a build error when the feature is encountered.

[zangbianxuegu]

@vitejs/plugin-legacy can indeed be a bit unintuitive, and it's important to carefully review the documentation.

• target specifies the syntax transformation range for legacy chunks.
• modernTargets specifies the syntax transformation range for modern chunks.
• polyfills specifies which polyfills should be included in the legacy chunks.
• modernPolyfills specifies which polyfills should be included in the modern chunks.

In your case, the issue likely arose because the plugin classified the browser as a modern browser based on its built-in detection mechanism (which checks for support of import.meta, dynamic import(), and async generators). As a result, it loaded the modern chunks, but since modernPolyfills was not set, the Object.hasOwn polyfill was missing in that environment, causing the error. Once you added modernPolyfills, the missing polyfill was injected into the modern chunks, resolving the issue.