Command-line parameter to force "module" instead of "commonjs" type?

[getify]

I'm aware that I can name a file with .mjs or set "type": "module" in package.json. I'm also aware of the --input-type=module CLI parameter.

What I'm not understanding is, why isn't there a way to pass a parameter flag to force module interpretation for the .js file I specify? Was there a reason that --input-type can only be used with string input and not to control module interpretation of a .js file?

I tried searching old issues to find this discussed but my searching failed me. I feel certain it must have been intentionally omitted, but I'm just trying to understand why?

[benjamingr]

@nodejs/modules

[benjamingr]

I vaguely recall a --entry-type

[benjamingr]

Further discussion from the modules repo nodejs/modules#296

I found two more issues, I think it's better to wait for someone who was active at the modules team to say what ended up happening that caused --entry-type (or --x-types) to be removed.

Edit: found it #27184

Edit2: found the reasoning nodejs/modules#300 (comment)

[getify]

Thanks for helping me find those links.

I completely disagree with the reasoning stated there (I don't care if it was "package-type" or "entry-type", just would want some way to do it)... but I don't have the energy to try to re-litigate it.

[DerekNonGeneric]

@getify, those decisions aren't etched in stone. We may be able to accommodate you especially if you would be interested in making a pull request. Having a flag as you describe does seem useful to me.

[ljharb]

If you're writing a file that has no associated package.json, how would you expect to convey (for invocations beyond the current one) the parse goal of the file beyond the extension, given that .js means Script and .mjs means Module, by default?

[targos]

Would there be a problem if we added a flag that allows the user to change the default behaviour ?

[ljharb]

@targos it would encourage people to use a file extension that doesn’t match the parse goal of their file, without an accompanying package.json to carry that information.

[WebReflection]

one more time: this is not a module

import {random} from 'library';
console.log(random());

the fact .mjs means module is absolutely misleading for any program that is not a module, just a program, written in JavaScript (.js).

All main bundles/files on the Web also are not modules: these are programs, that use a module system, yes, but these are not modules.

index.mjs is not a module, if it doesn't export a thing, is a program.

But yeah, this has been discussed for ages already.

[WebReflection]

Last one, for correctness, and completeness, sake:

<script type="module" src="program.js">

The type there doesn't practically define the parsing goal, it defines the module system, and it propagates with it, because program.js will import files, and these files implicitly inherit the module system, hence the parsing goal.

Something like:

node --type=module --force-type=true program.js

could enforce the module system and its propagation, so that by default everything imported by program.js would have a module system, by default, that is ESM, not CommonJS.

That's how you could define the parsing goal, but there's never been interest in doing this, although tons of developers keep asking for this, so I wish this common request was more welcomed, or developers expectations acknowledged.

I don't have the energy to try to re-litigate it

'cause this is sad, but from personal experience, also true ... current state is more opinionated than concrete, imho, while competitors factor out this gotcha for developers (see deno).

edit

node --default-type=module program.js
node --input-type=module --override-default-input-type=true

all variants that could make it, if there was the will to do so.

[getify]

Background

I built a tool called moduloze that converts a tree of commonjs-style files to either UMD or ESM style files. It's designed either to be used as a one-time codemod for code authors wishing to permanently convert to ESM, or (my use) for package authors who still prefer to write in commonjs but who want to distribute also in UMD and ESM formats for wider consumption flexibility. I have all my main/active npm packages using it.

Along with that, I also have a tool called import-remap which allows you to apply import-map style rewriting of your import specifiers as a build-tool (instead of runtime aliasing). I also use import-remap in some of my projects to modify the output from moduloze to be ESM that's more readily useable in the browser.

So, taken together, these two tools give authors a narrower-focused, and more flexible/less opinionated path (than, say, typical all-in-one bundlers) for supporting code that's CJS, UMD, and ESM, at the discretion of the users of my tools.

Note: It is not a goal to interop between formats, but to support building parallel trees of code for each format.

In that spirit, these tools (moduloze particularly) allow you to specify that you want your built ESM modules to be either .mjs or .js file extension. I offer that choice because I don't want my opinions on that topic to limit others. If they choose to make .js files with ESM code in them, they are responsible to either use that code in an environment like the browser where the script tag conveys the format, or in Node with some supporting configuration (e.g., a package.json).

Use-Case

I would like to be able to test the various combinations of outputs from my tools (both automated test suites, and user-opt-in verification steps when the tools are used on user-code).

I find it annoying/inconvenient to have to create a stub package.json file in a directory of built ESM-containing .js files with nothing but "type": "module" in it, just to force Node to treat this set of files with the proper parsing format.

It's mildly annoying to need it for my tool test suite, but it's especially annoying for the opt-in at-use-time verifications performed on user-code the tool just outputted, since such a file has to be created just to invoke Node then deleted right after... every time.

I would strongly prefer to have a flag like --package-type for that purpose.

---

I've read all the linked threads (and comments here) and I'm aware of the objections to such a feature -- i.e., general users can't/shouldn't be trusted with such a feature.

I disagree with these assertions, but don't need to have them repeated here, and I don't care to re-debate it. I've stated my use-case for posterity sake. I'll leave it at that, as I suspect it won't sway the strong opinions held by some in charge of Node's direction with modules.