legacy: support lowering to ES5

[martinarvaiaccedo]

Describe the regression

He vite team! First of all thanks for your hard work on the rolldown version, its amazing to see the performance benefits! We rely on vite legacy to build for old - and slow - smart tvs and set top boxes, therefore sometimes we need to go back even to ES5. With rolldown vite-legacy, I realized the polyfills-legacy chunk is not being transpiled and will have es6 code in. I managed to patch it to be working again.

Thanks for looking into this!

Root Cause

The buildPolyfillChunk() function generates a polyfills bundle using Vite/Rolldown, but the output is not transpiled to ES5. The chunk contains:

1. Core-js polyfills (ES6+ code)
2. SystemJS library code (ES6+ code)

Since the polyfills are meant to run before any other code on legacy browsers, they must be ES5-compatible. Modern bundlers don't transpile to ES5 by default.

Solution Applied

Added Babel transpilation to ES5 in buildPolyfillChunk() for legacy/iife format chunks:

if (format === "iife" && polyfillChunk && legacyTargets) {
  const babelTransformOptions = {
    babelrc: false,
    configFile: false,
    compact: !!minify,
    sourceMaps: !!sourcemap,
    sourceType: 'script',  // IIFE, not ES modules
    inputSourceMap: void 0,
    targets: legacyTargets,
    assumptions: babelAssumptions || {},
    browserslistConfigFile: false,
    presets: [[(await import("@babel/preset-env")).default, {
      bugfixes: true,
      modules: false,
      useBuiltIns: false,
      shippedProposals: true,
      exclude: ['transform-typeof-symbol']  // Critical: prevents breaking Symbol polyfills
    }]]
  };
  
  const result = babel$1.transform(polyfillChunk.code, babelTransformOptions);
  if (result) {
    polyfillChunk = {
      ...polyfillChunk,
      code: result.code,
      map: result.map
    };
  }
}

Also removed prependModenChunkLegacyGuardPlugin() from the polyfills build plugins - polyfills shouldn't have the modern browser guard export.

Impact

• Before: 335KB polyfills-legacy chunk with ES6+ syntax → crashes on Chrome 52
• After: 204KB polyfills-legacy chunk with ES5 syntax → works on legacy browsers

Notes

• exclude: ['transform-typeof-symbol'] is critical to prevent Babel from breaking Symbol detection in core-js polyfills
• sourceType: 'script' is required since the polyfills chunk is IIFE, not ES modules
• Main legacy entry chunks already get proper Babel transpilation via renderChunk(), but polyfills bypass that path

Here's a proposed patch - i didnt raise a PR as I was not sure if you plan to support this at all :)

@vitejs__plugin-legacy.patch

Reproduction

https://stackblitz.com/edit/vitejs-vite-xap7pp8d

Expected Behavior

polyfills-legacy chunk is not transpiled

Actual Behavior

should be transpiled to es5

Steps to Reproduce

Reproduce in this container https://stackblitz.com/edit/vitejs-vite-xap7pp8d?file=dist%2Fassets%2Fpolyfills-legacy-ULSa55Dz.js

• check polyfills-legacy, it contains arrow functions => even though target is chrome 38
• change back to normal vite in package.json and observe that it will build to legacy correctly

System Info

Envinfo can not be ran, interestingly.

Stacklbitz's:



  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: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @vitejs/plugin-legacy: 7.2.1 => 7.2.1 
    rolldown-vite:  7.1.17

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs and the Rolldown-related guide.
• Check that there isn't already an issue that reports the same regression to avoid creating a duplicate.
• Check that this is a concrete regression. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the regression.

[sapphi-red]

Normal Vite doesn't transpile the polyfill chunk because transpiling a polyfill is discouraged. To fix this without tranpiling the chunk, we need Rolldown to support output.generateCode: 'es5' (rolldown/rolldown#206).

[brendanmatkin]

The buildPolyfillChunk() function generates a polyfills bundle using Vite/Rolldown, but the output is not transpiled to ES5. The chunk contains:

Core-js polyfills (ES6+ code)
SystemJS library code (ES6+ code)

Since the polyfills are meant to run before any other code on legacy browsers, they must be ES5-compatible. Modern bundlers don't transpile to ES5 by default.

Correct me if I'm wrong, but I'm pretty sure those polyfills are not distributed in ES6+ code. i.e. systemJS runtime should work on IE11 ootb.

Normal Vite doesn't transpile the polyfill chunk because transpiling a polyfill is discouraged. To fix this without tranpiling the chunk, we need Rolldown to support output.generateCode: 'es5'

@sapphi-red So if I'm understanding correctly,what's actually happening is that when Rolldown is creating the legacy chunks/bundle, it actually transpiles the polyfill code to more modern javascript? edit: just re-read your comment and you literally said it doesn't transpile/transform 😬. Is 'syntax lowering' more appropriate, or is that considered the same as transpile in this context? Is this a consequence of the minification? I know plugin legacy doesn't use esbuild for minifying the legacy chunks because it is "not safe", so uses terser instead - is it a similar problem here? Or is it less about transpiling (/transforming/syntax lowering) the code, and more that it is importing all the bits, analyzing them and essentially writing new code to tie it all together (along with annotations and stuff).

Rollup's output.generatedCode:

Which language features Rollup can safely use in generated code. This will not transpile any user code but only change the code Rollup uses in wrappers and helpers. You may choose one of several presets: <es5 or es2015>

Assuming Rolldown's is essentially the same, then why does setting vite config build.rolldownOptions.output.generatedCode.preset to es5 not seem to work in Vite 8? Is plugin-legacy maybe overriding it? Here is the OP stackblitz modified for Vite 8 + generatedCode preset

Snippets from the two repro dist polyfill bundles; Vite 7 (rollup; "vite": "7.2.6") vs Vite 8 beta (with generatedCode.preset: 'es5'):

var functionUncurryThis;
var hasRequiredFunctionUncurryThis;

function requireFunctionUncurryThis () {
	if (hasRequiredFunctionUncurryThis) return functionUncurryThis;
	hasRequiredFunctionUncurryThis = 1;
	var NATIVE_BIND = requireFunctionBindNative();

	var FunctionPrototype = Function.prototype;
	var call = FunctionPrototype.call;
	// eslint-disable-next-line es/no-function-prototype-bind -- safe
	var uncurryThisWithBind = NATIVE_BIND && FunctionPrototype.bind.bind(call, call);

	functionUncurryThis = NATIVE_BIND ? uncurryThisWithBind : function (fn) {
		return function () {
			return call.apply(fn, arguments);
		};
	};
	return functionUncurryThis;
}

var require_function_uncurry_this = /* @__PURE__ */ __commonJSMin(((exports, module) => {
	var NATIVE_BIND$2 = require_function_bind_native();
	var FunctionPrototype$2 = Function.prototype;
	var call$14 = FunctionPrototype$2.call;
	var uncurryThisWithBind = NATIVE_BIND$2 && FunctionPrototype$2.bind.bind(call$14, call$14);
	module.exports = NATIVE_BIND$2 ? uncurryThisWithBind : function(fn) {
		return function() {
			return call$14.apply(fn, arguments);
		};
	};
}));

[brendanmatkin]

Small update: doing the reverse - setting build.rollupOptions.output.generatedCode.preset: 'es2015' (default is es5), doesn't change the output in vite 7. Neither does build.rollupOptions.output.generatedCode: '2015'. Nor any variation of:

build: {
  minify: false,
  modulePreload: { polyfill: false },
  rollupOptions: {
    output: {
      generatedCode: {
        preset: 'es2015',
        arrowFunctions: true,
        constBindings: true,
      },
    },
  },
},

So I'm clearly missing something here.

I'm going to try this again later with a fresh project. Maybe something else is wonky.

[sapphi-red]

why does setting vite config build.rolldownOptions.output.generatedCode.preset to es5 not seem to work in Vite 8?

It's because Rolldown doesn't support it (rolldown/rolldown#6701).

[brendanmatkin]

It's because Rolldown doesn't support it (rolldown/rolldown#6701).

Ah k I was thinking, since the docs say rolldown supports output.generatedCode.preset: 'es5', it was just a syntax thing. Is it just not fully implemented yet?

... to answer my own question here, yes. It looks like it's just starting to be implemented (only symbols so far): generated_code_options.rs

Rollup preset:

es5: {
  arrowFunctions: false,      // not in Rolldown
  constBindings: false,       // not in Rolldown
  objectShorthand: false,     // not in Rolldown
  reservedNamesAsProps: true, // not in Rolldown
  symbols: false              // implemented in Rolldown
}

HOWEVER - RollUP in Vite 7 doesn't use generatedCode

tldr; rolldown is transforming inputs significantly (with es6+ syntax) when polyfillling require, rollup uses @rollup/plugin-commonjs that doesn't transform the code so much.

My point with the Vite 7 tests was to check if we are barking up the wrong tree with generatedCode:

So my tests with Vite 7 vs Vite 8 are still accurate - even in a fresh Vite 7 install, changing the generatedCode options in vite config doesn't change the formatting of the polyfills-legacy bundle. vite-plugin-legacy doesn't actually use the generatedCode options - the buildPolyfillChunk function (which is what calls vite build()) doesn't access anything in rollupOptions.build.output.generatedCode. To build the inlineConfig, it either destructures or directly accesses properties of both opts and config.build, neither of which include generatedCode.

I think the key is actually the way rolldown does require polyfill. This is the hint in vite-plugin-legacy's code:

//...build({...build: { ...
// Don't run esbuild for transpilation or minification
// because we don't want to transpile code.
esbuild: false,
optimizeDeps: {
  esbuildOptions: {
    // If a value above 'es5' is set, esbuild injects helper functions which uses es2015 features.
    // This limits the input code not to include es2015+ codes.
    // But core-js is the only dependency which includes commonjs code
    // and core-js doesn't include es2015+ codes.
    target: 'es5',
  },
},

I don't think optimizeDeps is actually used for the call to build(), but the hint is that Vite 7 uses @rollup/plugin-commonjs as part of all builds, where I think Vite 8 uses internal logic. Related issues and PR:

• [Feature Request]: Support transforming CJS require calls into ESM imports rolldown/rolldown#2041
• [Feature Request]: Make require('external') runnable in any execution context if possible rolldown/rolldown#2685
• feat(node/esm): polyfill require if format: 'esm' and platform: 'node' rolldown/rolldown#2920

The code matches the theory:

core-js fails.js:

'use strict';
module.exports = function (exec) {
  try {
    return !!exec();
  } catch (error) {
    return true;
  }
};

Vite7 with rollup legacy polyfill snippet:

var fails;
var hasRequiredFails;

function requireFails () {
	if (hasRequiredFails) return fails;
	hasRequiredFails = 1;
	fails = function (exec) {
	  try {
	    return !!exec();
	  } catch (error) {
	    return true;
	  }
	};
	return fails;
}

Vite 8 rolldown legacy polyfill snippet:

var __commonJSMin = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);
var require_fails = /* @__PURE__ */ __commonJSMin(((exports, module) => {
	module.exports = function(exec$3) {
		try {
			return !!exec$3();
		} catch (error) {
			return true;
		}
	};
}));

Maybe generatedCode actually is the fix here, so it gets transpiled/syntax lowered a second time. That's over my head. But it made no sense to me that babel + core-js were outputting code that needed to be transpiled to work on older browsers AFTER going through preset-env, so I had to dive in for a bit. Hopefully it's helpful. I just upped my ADHD meds so please excuse the hyper-focused over-complicated post lol