Babel-node not working with "type": "module" in package.json

[subhero24]

I have the following script that I'm running with npx babel-node script.js

let a = 0;
let b = 1;
console.log(a ?? b);

It executes fine with my babel config

{
	"plugins": ["@babel/plugin-proposal-nullish-coalescing-operator"]
}

When I add "type": "module" to my package.json file, the npx babel-node script.js command fails to run and I get the error SyntaxError: Unexpected token '?'.

So it seems specifying my package as module, prevents babel-node from loading the babel config?

[babel-bot]

Hey @subhero24! 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."

[nicolo-ribaudo]

This is currently expected. @babel/register (used by @babel/node) only works with CommonJS scripts, because Node.js doesn't have a stable API yet to intercept ES modules loading.

[JLHwung]

Worth add a note to https://babeljs.io/docs/en/babel-register that babel-register does not support compiling native Node.js es modules on the fly.

[sidntrivedi012]

I would like to help out in this doc fix.

[sidntrivedi012]

Should we close this issue since it has been solved in babel/website#2177 ?

[farwayer]

The problem is if you set type: module in package.json then your babel.config.js must be in module format (or you will get Error while loading config - module is not defined error).

And babel config in esm format works fine with @babel/cli but not with @babel/register. So for now it is not possible to have type: module and using babel-node.

[nicolo-ribaudo]

You can use babel.config.json or babel.config.cjs.

[farwayer]

Thanks for response! I can't use babel.config.json because of dynamic configuration logic based on caniuse-api. I already tried babel.config.cjs but with no luck. It works with @babel/cli but @babel/node do not use it.

[nnmrts]

Alright so is there no way to use a dynamic config while also having "type": "module" in your package.json?

[bradley]

So what is the suggestion here? My understanding is that we use @babel/node for developing a node backend with babel configuration, and then we are supposed to compile the backend using the babel cli for production. In order to keep using import in my node app, I use "type": "module" for the compiling step.... which breaks @bable/node and therefore development... this seems like an issue to me, shouldn't this be reopened?

[mdierolf]

This is a nasty issue once you run into it - this essentially is keeping me from being able to use newer javascript features and native ES modules alongside one another - it breaks babel-node which is used in development

[nnmrts]

Yeah this issue is sad. I'm "okay" with transpiling stuff, but the reason we are transpiling is so that we can use newer Javascript while browsers will still understand it. But we are not only using newer Javascript because it's cool, we also use it because it's "future-proof". There is a hope that one day you can remove all this transpiling and just give the browser the source code and everything works fine. This is basically what you are aiming for...right? With this issue, my source code will never be compatible with any browser in the future, it will only be compatible with babel. @JLHwung, why is this issue still closed?

[mdierolf]

When the @babel/register hook isn't available, @babel/node should probably just transpile the whole app into a temp directory, and then run the node executable on the file so it at least "works"

Yeah this issue is sad. I'm "okay" with transpiling stuff, but the reason we are transpiling is so that we can use newer Javascript while browsers will still understand it. But we are not only using newer Javascript because it's cool, we also use it because it's "future-proof". There is a hope that one day you can remove all this transpiling and just give the browser the source code and everything works fine. This is basically what you are aiming for...right? With this issue, my source code will never be compatible with any browser in the future, it will only be compatible with babel. @JLHwung, why is this issue still closed?

[JLHwung]

With this issue, my source code will never be compatible with any browser in the future, it will only be compatible with babel.

Keep in mind that @babel/node is not the only way to use Babel, you can use @babel/cli or bundlers like webpack and rollup -- @babel/node is meant to be used in development/testing only. Transpiling a file on-the-fly is slower than executing the transpiled files. As said before in #11108 (comment) if @babel/node would support type: "module", it will rely on hooks about ES modules, this feature is still experimental, the API signature may change and Node.js suggest do not rely on that.

When the @babel/register hook isn't available, @babel/node should probably just transpile the whole app into a temp directory, and then run the node executable on the file so it at least "works"

This won't work for dynamic import() since people can import any file and that should be compiled by Babel on module hooks.

I think we can throw purposely on type: "module and mention that we are waiting Node.js to finalize the ESM hooks API.

[nnmrts]

With this issue, my source code will never be compatible with any browser in the future, it will only be compatible with babel.

Keep in mind that @babel/node is not the only way to use Babel, you can use @babel/cli or bundlers like webpack and rollup -- @babel/node is meant to be used in development/testing only. Transpiling a file on-the-fly is slower than executing the transpiled files.

Yeah, but that's what I'm saying. Of course it's way slower now, in the present, but it's about being able to use the same exact code in the future without transpiling. It's about writing as much standard code as possible, to reduce future changes to it the moment you can actually use this code as it is, when browsers support these standards as well.

Idk, that's at least how I understood it. I know that using Node.js itself while developing a webapp for example, is already not the "standard" ES way of doing it. But at least, at the moment, if I would write only supported ES code, without external modules, but also use dev tools like eslint and babel locally (which rely on node.js) just to make my dev experience better, I could in fact put this directory on a server with an index.html and it would just work.

The moment I'd want to introduce a dynamic babel config, the whole thing breaks. Either I have to use commonjs module style for my whole project, transpile it and deploy it like that, or I have to live without babel and eslint. Of course, all that seems risky and at the current state, you still would want to transpile your code to support every reasonable browser out there, but why should the source code change for that? The dist code can change all it wants, no problem, but at the moment I'm forced to make small changes to actually working standard code.

I'm curently totally fine with that and I fully understand that this isn't top priority, and that we have to wait for dependencies like Node.js to support this kind of coding, where you write standard ES code, everywhere from your source code, to your config files. What I'm trying to say here is that this issue isn't "solved", it shouldn't be closed, because like @nicolo-ribaudo said

This is currently expected.

but it isn't expected forever. Node.js itself apparently needs to work on that stuff as you said, and the suggestion

I think we can throw purposely on type: "module" and mention that we are waiting

is a perfect one, but still, this issue shouldn't be closed, just because it is blocked.

That's effectively all I'm saying. This issue was closed way too fast and I'm just wondering if there will be (or already is) a follow up issue or if this issue here will be reopened, otherwise I don't know how one would keep track of it. I know this seems pedantic, but I just feel like there is no current "tracker" of the progress of @babel/register and Node.js, respectively supporting compiling native ES modules on the fly. This issue could be that tracker, so my suggestion would be to reopen it.

[nicolo-ribaudo]

@nnmrts I think you misunderstood this issue. You can successfully use ES modules with Babel on Node.js and I'm doing it in different projects.
You can use ES modules to write your Babel config.

The only thing that you cannot do is using the @babel/node and @babel/register packages.

[nicolo-ribaudo]

Btw, if you really want to rely on an unstable Node.js API to compile modules on the fly, you can use https://github.com/targos/multiloader which supports Babel

[nnmrts]

@nnmrts I think you misunderstood this issue. You can successfully use ES modules with Babel on Node.js and I'm doing it in different projects.
You can use ES modules to write your Babel config.

The only thing that you cannot do is using the @babel/node and @babel/register packages.

So you are saying I'm able to write my babel.config.js, my eslint config, my rollup config and my actual source code all in ES module syntax? Including support in my IDE (vscode)?

Because last time I checked, that wasn't the case, something always broke down and I had to use the cjs syntax and file extension for my configs, and even then, my toolchain somewhere complained that I "must use import to load ES Module" even though that's exactly what I'm doing.

I'll revisit my repository in which I had these issues and see if it's working now somehow.

[nicolo-ribaudo]

I'll create a demo repo to share! The only problem is that you cannot use @babel/node and @babel/register.

[nicolo-ribaudo]

https://github.com/nicolo-ribaudo/babel-native-esm-demo

my eslint config, my rollup config

I don't know if those tools support native ESM configs, but Babel does.

[nnmrts]

@nicolo-ribaudo Thank you for now, I'll look into it.

[nnmrts]

Maybe I'm really just dumb and used an old version of babel or something, idk. It was roughly a week ago where my project stopped working.

[nicolo-ribaudo]

I just realized that it doesn't work with webpack, I'll review babel/babel-loader#825 so that it can work.