esm: add limited support for --print

[aduh95]

The idea is to enable the following use-case:

$ ./node --input-type=module -p 'await fetch("https://nodejs.org/docs/latest/api/index.json").then(r=>r.json())'   
{ type: 'module', source: 'doc/api/index.md' }

Obviously it only work for a tiny portion of modules (only modules that have a single expression that is not import or export), but since there was no support at all before this PR, it's not going to break anyone.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[ghiscoding]

this seems similar to the updated bun --print as shown in their latest v1.0.31#new-bun-print blog post. The only exception might be that Bun doesn't require the await, it will await even without it when a Promise is detected. Note that I'm not using this Node command, I just thought of adding this note for comparison sake. Cheers

[GeoffreyBooth]

Does the following work?

node --input-type=module --print "import { version } from 'process'; version"

The CJS equivalent node --print 'const { version } = require("process"); version' does.

[aduh95]

Does the following work?

node --input-type=module --print "import { version } from 'process'; version"

The CJS equivalent node --print 'const { version } = require("process"); version' does.

No, as said in the description and can be seen in the tests, this PR adds support for single expression modules only. import { version } from 'process'; version didn't work before, and still doesn't work with this PR. The alternative would be

$ node --input-type=module --print 'await import("node:process").then(({ version }) => version)'
22.0.0
$ node --input-type=module --eval "import { version } from 'process'; console.log(version)"
22.0.0
$ node --input-type=module --print 'process.version'
22.0.0
$ node --version
22.0.0

[MoLow]

Suggested change

	source = `console.log((${source}))`;
	source = `console.log(await (async(() => {${source}})()))`;

will wrapping source with an async iife make multiple expressions and missing await work?

[aduh95]

It would force the user to write return, which would be weird (let’s not forget that using return at the top-level of a module is not valid syntax)

[GeoffreyBooth]

I feel like if --print supports multiple expression CommonJS input, if we can’t get it to work likewise for ESM input we should at least error informatively so that the user knows how to fix their input so that it works.

[aduh95]

I feel like if --print supports multiple expression CommonJS input, if we can’t get it to work likewise for ESM input we should at least error informatively so that the user knows how to fix their input so that it works.

Do you have something in mind regarding what that would look like?

[GeoffreyBooth]

Do you have something in mind regarding what that would look like?

Could multiple expressions be turned into one by wrapping them in an IIFE? So like “It looks like you wanted to run multiple lines of code; however, --print for ES module code can only accept a single expression. Wrap your code in an immediately executing function, like (async () => { … })(), to convert your multiple lines into a single expression.”

[aduh95]

It's unclear how we could detect if the user is trying to run multiple lines without parsing their code – which maybe is what we should actually do. Note that the async IIFE won't help with import/export expressions.

[GeoffreyBooth]

which maybe is what we should actually do.

I think there’s some precedent for this, like maybe in --eval (?) on error we use Acorn to check for import/export to prompt the user to add --input-type=module.