Hey @kriskowal! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite."

@erights recommended that I call upon @jdalton or @bmeck for help with this issue. Time permitting, I’ll attempt to isolate this further. I’m not familiar enough with ESM or Babel at this point to tell whether this is an issue that lies more squarely with Babel or Node.

This is a known issue per how CJS files are only able to generate default exports in order to conform to the ECMAScript specification and binding behavior of ESM. Babel ships a CJS build to package managers and is why this behavior exists. esm contains a variety of conveniences that hook into a variety of transpilation patterns such as the __esModule:true behavior of not creating synthetic module namespaces and otherwise picking properties to form namespaces otherwise.

@bmeck, I read your statement as “This is not a Node.js bug. Using Babel as it is written today depends on crutches of ESM that will vanish soon. Babel will need to change to accommodate Node.js.” Is this correct? Can you propose a rule that Babel would need to follow to straddle CJS and ESM, like “Avoid default exports.”?

@kriskowal I wouldn't phrase it as such since I don't actually think this is a bug but an integration problem by the nature of the transpilation; note that babel file in question is CJS and CJS does not export named bindings in Node. I wouldn't state that importing CJS is broken on Node's side, nor would I state that babel creating CJS from ESM input is broken. They just don't mix / no solutions have been able to be found. There are lots of issues exactly about this topic, from things on Node trackers, at TC39, and many more. In general mixing the transpiled ecosystem and spec ESM simply doesn't work as it stands. So, once you cross the transpilation barrier things must adhere to their compilation target expectations (in the case of @babel/core that is CJS). I think babel could output ESM instead of CJS like rollup does, but even then more integration issues likely remain.

We might decide to change this in Babel 8, but in the meantime use import babelCore from "@babel/core".

@nicolo-ribaudo Thank you! That is a fine work-around. Feel free to close if you do not require this task to track.

I'll defer the decision to @JLHwung, since he recently started investigating Node.js's new export maps which are related to this.

I agree on what Bradley has said before: @babel/core is shipped in commonjs, if you are looking at the entry file, it is like

exports.transformSync = require("./transform").transformSync

The ESM named import import { transformSync } from "@babel/core" is never expected to work with commonjs exports.transformSync.

The esm will transform the commonjs exports to analogous esm exports so node -r esm works in your case.

We are likely to ship dual cjs/esm builds of babel on Babel 9, which is expected in next year. So in the future it should be valid to do

import * as babelCore from "@babel/core" // the esm entry is imported

At this moment the Node.js ES Module API is still experimental and Babel 8 is on the horizon, it is risky to ship esm builds for Babel 8. Before that please use

import babelCore from "@babel/core"

since @babel/core, although written in ESM, is actually shipped in commonjs format.

I am gonna close that because the current situation is expected.