Add an option to include non-legal identifier named exports to dataToEsm function of pluginutils

[sapphi-red]

• Rollup Plugin Name: pluginutils
• Rollup Plugin Version: 5.0.2

Feature Use Case

Currently dataToEsm function of pluginutils skips named exports for non-legal identifiers.

plugins/packages/pluginutils/src/dataToEsm.ts

Lines 84 to 96 in bc5cf91

	if (key === makeLegalIdentifier(key)) {
	if (options.objectShorthand) defaultExportRows.push(key);
	else defaultExportRows.push(`${key}:${_}${key}`);
	namedExportCode += `export ${declarationType} ${key}${_}=${_}${serialize(
	value,
	options.compact ? null : t,
	''
	)};${n}`;
	} else {
	defaultExportRows.push(
	`${stringify(key)}:${_}${serialize(value, options.compact ? null : t, '')}`
	);
	}

For example, dataToEsm({ foo: 0, 'foo.bar': 0 }, { namedExports: true }) generates the following code.

export var foo = 0;
export default {
        foo: foo,
        "foo.bar": 0
};

ES2022 introduced Arbitrary module namespace identifier names(tc39/ecma262#2154) feature that allows exporting non-legal identifiers. By taking advantage of this, we are now able to export variables with any names that is a valid "Well-Formed Code Unit Sequence".
With the previous example, we can generate the following code.

export var foo = 0;
var __arbitary0 = 0;
export { __arbitary0 as "foo.bar" };
export default {
        foo: foo,
        "foo.bar": 0
};

Related: vitejs/vite#11359

Feature Proposal

Add allowStringAliasedNamedExports: true option to dataToEsm that generates the code above.
The reason why I don't propose this to be a default behavior is because arbitrary module namespace identifier names is not transpilable (esbuild errors, swc skips).

If a breaking change is acceptable, I think the option can be merged with namedExports option.

• namedExports: false: same with current false
• namedExports: 'non-aliased': same with current true
• namedExports: 'aliased': the proposed one

[stale]

Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ