Extensionless files should allow --input-type (or work)

[pinko-fowle]

Currently it seems impossible to have an extensionless esm file. I get errors like the following:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension "" for /Users/pinko-fowle/src/myutil/bin/dev. Loading extensionless files is not supported inside of "type":"module" package.json contexts. The package.json file /Users/pinko-fowle/src/myutil/package.json caused this "type":"module" context. Try changing /Users/pinko-fowle/src/myutil/bin/dev to have a file extension. Note the "bin" field of package.json can point to a file with an extension, for example {"type":"module","bin":{"dev":"./bin/dev.js"}}
    at new NodeError (node:internal/errors:405:5)
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:79:11)
    at defaultGetFormat (node:internal/modules/esm/get_format:124:36)
    at defaultLoad (node:internal/modules/esm/load:84:20)
    at nextLoad (node:internal/modules/esm/loader:163:28)
    at ESMLoader.load (node:internal/modules/esm/loader:603:26)
    at ESMLoader.moduleProvider (node:internal/modules/esm/loader:457:22)
    at new ModuleJob (node:internal/modules/esm/module_job:64:26)
    at #createModuleJob (node:internal/modules/esm/loader:480:17)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:434:34) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'

In general this has been a super frustrating transition. It seems like it would make all the sense in the world to just be able to tell node what the script is. So I tried passing --input-type module, thinking, surely, if I tell you, you must be ok with this, yes?

Unfortunately this also doesn't work. I get:

Error [ERR_INPUT_TYPE_NOT_ALLOWED]: --input-type can only be used with string input via --eval, --print, or STDIN

I'd love to be able to get extensionless esm modules working. The current advice to add an extension, or define an npm script are both really ugly alternatives that keep Node.js ESM scripts from being able to fit in & look clean like anything else on the system. Adding --input-type support seems like an obvious & sensible fix. But any option at all would be fine, to get esm scripts working like anything else on a system would.

[pinko-fowle]

Ooops, repo not active. Moving.

[ljharb]

Yes, this is impossible, intentionally.

[pinko-fowle]

Do note that your "in your brand" comment violates the CoC, and is unnecessarily hostile, and on top of that, I can't recall us ever interacting before.

Where is a good way to provide feedback that you don't listen to users and assert your correctness overtop of other people, and make them feel bad for expressing struggles they face?

I did find many other threads, but I've still found nothing actually describing or justifying this particular decision about --input-type. I've seen it stated as an issue, but not why or when that decision was made. I've seen comments about how users might expect it (#300 (comment)), and how it may well need to be revisited down the road. I'm still looking for any information why things are the way they are.

(And for reference (but without linking), node #49295 has more ongoing discussion of this issue)

[ovflowd]

Do note that your "in your brand" comment violates the CoC, and is unnecessarily hostile, and on top of that, I can't recall us ever interacting before.

Where is a good way to provide feedback that you don't listen to users and assert your correctness overtop of other people, and make them feel bad for expressing struggles they face?

Hey @pinko-fowle, there's a genuine misunderstanding happening here. I genuinely believe that @ljharb wasn't trying to put salt in your wounds but to answer your initial issue that this issue you're facing is intentional by design. He probably didn't add more details because none were asked.

Your comment also might imply that you're asserting your points over Jordan's, nullifying your point... Or at least that's how I would interpret the comment; my apologies if I did misinterpret it!

I'm sorry you've felt that @ljharb answer was not what you'd expect, regardless of that the "in your brand" comment is kinda of unnecessary.

Let's keep this conversation healthy :)

[ljharb]

You are welcome to provide personal feedback in private; I'm eminently reachable on most mediums. Providing it in public is rarely productive, for anyone.

[WebReflection]

Yes, this is impossible, intentionally.

@pinko-fowle please listen to hints around respecting the CoC but when you read these answers just move to bun and call it a day, as this argument has been around for years but Node.js is strongly convinced CJS should stay forever (as non-standard default too).

This, as example, is an extensionless bun file you can run without issues and call it whatever you like:

#!/usr/bin/env bun

import { readFile } from 'fs';

console.log(readFile);

In short, the problem is solved elsewhere and many hope one day node will just work with the ECMAScript standard its built on, but that's not happening any time soon, as answers can tell you.

[ljharb]

While you're certainly free to use bun or anything else, this is an arena that ecma262 simply doesn't cover, also intentionally, so there's no "obvious" approach and certainly no standard one of any kind.

[WebReflection]

this is an arena that ecma262 simply doesn't cover,

the same arena where ESM is the only module option available, right?

[ovflowd]

Hey y'all, can we please stay on-topic?

[WebReflection]

@ovflowd what's not on topic when ecma262 is mentioned as the blocker while ecma262 only knows ESM ?

but surely I'm out this thread 👋

[Trott]

I locked this thread as there are other threads where this conversation can happen and this one is closed and more heated than I'd like to see.