Feature Use Case

Rollup gained support for native ESM configs in #3445. This feature enables Rollup to "give up" transpiling and let Node.js execute the raw ESM. However, support for ESM configs are still flaky at the moment:

• Rollup requires Node.js >= 13 to support native ESM config. However, native ESM is well-supported in Node.js v12.x as well. In 12.17.0, the --experimental-modules flag was made redundant; in 12.22.0 native ESM was declared "stable".
  Node.js v12 is scheduled to be maintained until April 2022. In the meantime, many projects staying on v12 will be unable to use native ESM for their Rollup config file.
  See:

  rollup/cli/run/loadConfigFile.ts

  Lines 15 to 17 in a4a3b8a

  	function supportsNativeESM() {
  	return Number(/^v(\d+)/.exec(process.version)![1]) >= 13;
  	}

  • This can be fixed by changing the constant, or by using a proper semver comparison.

• When package.json has "type": "module", Node.js treats all scripts with the .js extension as native ESM. This behavior was introduced in Node.js 12+. However, Rollup does not respect this field when consuming rollup.config.js: it still transpiles the config to CJS before passing it to Node.js.
  This becomes a problem if the config file imports a pure ES module: Because Rollup transpiles the imports to require()s, the build fails with "Node tried to require an ES module from a CommonJS file, which is not supported.".
  See:

  rollup/cli/run/loadConfigFile.ts

  Lines 115 to 123 in a4a3b8a

  	if (err.code === 'ERR_REQUIRE_ESM') {
  	return error({
  	code: 'TRANSPILED_ESM_CONFIG',
  	message: `While loading the Rollup configuration from "${relativeId(
  	fileName
  	)}", Node tried to require an ES module from a CommonJS file, which is not supported. A common cause is if there is a package.json file with "type": "module" in the same folder. You can try to fix this by changing the extension of your configuration file to ".cjs" or ".mjs" depending on the content, which will prevent Rollup from trying to preprocess the file but rather hand it to Node directly.`,
  	url: 'https://rollupjs.org/guide/en/#using-untranspiled-config-files'
  	});
  	}

  • This cannot be "fixed" without breaking existing code that may be relying on Rollup transpiling the config.

While these two issues can be resolved separately, we may expect further edge cases until the ecosystem adapts to native ESM. Rollup's "should I transpile the config?" detection method may not reflect the interests of its users. Furthermore, changes in the detection method would break existing code that relies on the current behavior. Therefore, it would be nice to give users an escape hatch that gives full control over whether Rollup should transpile its config file.

Feature Proposal

Add a --[no--]skip-config-transpile CLI flag. --skip-config-transpile will force Rollup not to transpile the config, and --no-skip-config-transpile will force Rollup to transpile the config. In both cases, Rollup leaves the decision up to the user; it forgoes checking the version of Node.js or the config file extension.

Some notes:

• If either flag is not provided, Rollup retains the current behavior. This maintains backwards compatibility.
• Since the decision to transpile a config file must be made before loading the config, we cannot control this behavior through the config file itself. This has to be a CLI flag.
• When the ecosystem around native ESM solidifies, Rollup could change the default behavior without worrying about large-scale breakage.