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

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?

2 thoughts on “Command-line parameter to force “module” instead of “commonjs” type?

  1. 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.

  2. 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.