Repository navigation
Allow flexible node script names in esm #37512
Description
Activity
@rektide can you expand a bit more on the version of Node.js you are using and if you perhaps have a rogue package.json with
type: modulesomewhere in you path between where you are trying to run this code and root?On my system with a stock installation of Node.js 12 / 14 / 15 the extensionless script works as expected.
edit: sorry about closing, mistype
@MylesBorin i am trying to use esm at the same time. that's definitely a compounding factor; should have mentioned that. i have updated the issue to be more esm specific & to not regard this as a regression. thank you. i am on version 12.20.2 atm, happy to test others.
perhaps the final option might be a sensible-ish one? there don't need to be separate binaries. but if node is symlinked then run as
nodemjsthen we know what module type we are. i'm not sure what this pattern is called, but it's how programs like busybox work. this would permit the followinghello-world:#!/usr/bin/env nodemjs console.log("hello esm world")
one other option (that i added to the list), seemingly less radical: i tried using
--input-type=modulebut got:internal/process/esm_loader.js:74 internalBinding('errors').triggerUncaughtException( ^ Error [ERR_INPUT_TYPE_NOT_ALLOWED]: --input-type can only be used with string input via --eval, --print, or STDIN at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:778:13) at Loader.resolve (internal/modules/esm/loader.js:100:40) at Loader.getModuleJob (internal/modules/esm/loader.js:246:28) at Loader.import (internal/modules/esm/loader.js:181:28) at internal/modules/run_main.js:46:28 at Object.loadESM (internal/process/esm_loader.js:68:11) { code: 'ERR_INPUT_TYPE_NOT_ALLOWED' }if it were possible to relax this we could make
hello-worldas so:#!/usr/bin/env -S node --input-type=module console.log("hello world")- changed the title
[-]Allow flexible node script names again[/-][+]Allow flexible node script names in esm[/+]on Feb 25, 2021 This behaviour is also breaking other tools assumptions, such as Emscripten (emscripten-core/emscripten#13551).
Other alternatives to solve this:
- Add a
package.jsonfield to opt-in to extensionless ESM - Keep the same behaviour as CJS (allow file with unknown extensions) but produce a runtime warning.
Reacted by rektide and Tom Ballinger- Add a
I had someone reach out to me recently with a related but different problem where their extensionless executable scripts are now failing if a package.json end up anywhere between their script and the root of the file-system that is "type": "module".
Thinking through a couple different potential solutions
Is your feature request related to a problem? Please describe.
I like to write esm scripts that users can use in Node.js. Pre-esm Node would allow this & just work. But there does not seem to be an esm-supporting way to do this. Previously I could make a short script
hello-world:And running it
./hello-worldwould work. Today if I do that with an module type script, I get:I do not want to subject my users to having to have every random utility I write end in .js: that adds no value to the user.
Describe the solution you'd like
Please allow unknown (or even just non-present) file extensions to be evaluated as javascript, using the same module or common heuristic as if it were a .js file.
Describe alternatives you've considered
--input-type=to work even if a file is specified (presentlycan only be used with string input via --eval, --print, or STDIN)nodecjsnodemjsnodewasmnodenodeuse the specified format. Symlink these names to the node binary.