Error TRANSPILED_ESM_CONFIG provides insufficient information

[flying-sheep]

Rollup Version

2.78.1

Operating System (or Browser)

Linux/Firefox

Node Version (if applicable)

No response

Link To Reproduction

https://replit.com/@flying-sheep/rollup-repro-esm-from-ts

Expected Behaviour

Until fixing the underlying bug #4617, I’d expect the error message to

1. Offer a solution that actually has a chance of working (I can’t rename a typescript file to .cjs or .mjs)

2. The actual problem can only be debugged knowing the content of the discarded original error’s message, which tells me which imported module causes the error.

   Error: require() of ES Module <projdir>/node_modules/@mdx-js/rollup/index.js from <projdir>/rollup.config.ts not supported.
   Instead change the require of index.js in <projdir>/rollup.config.ts to a dynamic import() which is available in all CommonJS modules.
   

Actual Behaviour

An encountered node error with code ERR_REQUIRE_ESM gets converted into a rollup error with code TRANSPILED_ESM_CONFIG, in the process discarding vital information to figure out where that happened:

rollup/cli/run/loadConfigFile.ts

Lines 127 to 129 in bf1ff32

	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.`,

I encountered this utterly unhelpful error,

[!] Error: While loading the Rollup configuration from "rollup.config.ts",
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.

[lukastaegert]

It should be possible to add the original error to the other error message. As by my other post, as transpilation to CommonJS is currently mandatory for TypeScript, a more helpful advice would be to place the config in a sub-folder with a package.json with type: "commonjs". This advice could always be given instead of the original error message when a command plugin is used, as in that case, transpilation is required.

PRs for both improvements are very much welcome.

[lukastaegert]

Fix at #4621

[flying-sheep]

Very cool! Will 3.0 be released soonish? Otherwise quality of life improvements like this should probably also be back ported to the 2.x branch, no?

[lukastaegert]

It will be released in the next two months. And no, we cannot back port because it is a major breaking change.

[lukastaegert]

There will probably be another pre-release with the change in the next week.

[flying-sheep]

Thanks for the info, i really like a transparent and responsive maintenance style! I didn't know you considered a new error type a breaking change. A backwards compatible way would be to enhance the existing error with full information, but I'm happy with a pre release too!

[lukastaegert]

It is not merely a new error type, this completely changes how modules are loaded. Basically for the TypeScript case, we switched CJS output with ESM output (with the ability to switch back to CJS output), but the same error was also fixed for the plain JavaScript case, where the fix is to no longer bundle in any case, which has very deep implications.

[flying-sheep]

Ah, i meant to backport only the \n\nOriginal message and stack: originalError.stack parts, but as said, I'm happy with the prerelease

[rollup-bot]

This issue has been resolved via #4621 as part of rollup@3.0.0-5. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-5 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4621 as part of rollup@3.0.0-6. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-6 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4621 as part of rollup@3.0.0-7. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-7 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4621 as part of rollup@3.0.0-8. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-8 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4621 as part of rollup@3.0.0. You can test it via npm install rollup.