A thought I wanted to run up the flagpole and get a feel for whether it makes any sense:
Since the migration to ESM within Gjs, typical GNOME JavaScript code is now a module that needs to be run with the -m flag to gjs.
That can be a problem when using shebang lines and execute bits to make JS files “runnable” directly — if you want to use a #!/usr/bin/env shebang, you now have to pass it the -S flag in order for it to interpret gjs -m as a command and a separate argument, instead of a single command string:
#!/usr/bin/env gjs -m
// You lose, env tries to launch the program 'gjs -m' which does not exist
#!/usr/bin/env -S gjs -m
// This works
And as I’ve recently learned, some envs — at least the one supplied by BusyBox — don’t support -S. Just has no idea what to do with it, apparently. So there’s actually no way to write a /usr/bin/env shebang that runs the file in gjs with the -m argument included, if the /usr/bin/env is a BusyBox symlink.
OK, sure, the shebang can be switched to #!/usr/bin/gjs -m, as long as you’re OK with hardcoding the path to gjs. (And incurring the wrath of Nix packagers, for whom that’s not going to fly.)
So I was thinking, what if gjs supported the already-sorta-standardized (well, Node kinda halfheartedly tried to make it happen) .mjs extension for JavaScript module files, specifically? And automatically ran them as modules without requiring an explicit -m on the command line? So that, in other words, gjs mycode.mjs becomes equivalent to gjs -m mycode.js.
Then, the shebang for a mycode.mjs file can simply be #!/usr/bin/env gjs, and everyone walks away happy.
Anything I’m missing, about why that wouldn’t work?