Allow use without a file extension about zx

[rattrayalex]

To me, "no extension" means "a script I can execute from the command line". In other words, I try to avoid a file extension for any file with a shebang at the top and chmod +x applied to it. Maybe that's just me though! 🤷

If it helps, here's an example of how another project recently accomplished this: code, issue.

[antonmedv]

Actually we can make a workaround this problem by writing script with extension to separate file and executing it.

[antonmedv]

It will cool to have VSCode extension for zx. And with it we can allow omitting extension.

[antonmedv]

Done!

[earslap]

Actually we can make a workaround this problem by writing script with extension to separate file and executing it.

Thank you for implementing this feature.

Right now the mjs script is generated in the same folder as the executable, and it is cleaned up when the script exits. But if you close the script midway with ctrl + c, or any type of process.exit() is executed from within the script, this generated file is unfortunately not cleaned up. Moreover, in future invocations (and possible cancellations) newer and newer files are generated (with random suffixes to prevent clashes) and they pile up.

Is there a particular reason for generating this temporary file in the same location as the original script? I don't think making sure that the cleanup happens properly in each case would be trivial (or possible). Would it be better to generate this in a system's temp folder so that no matter what happens, they are cleaned by the system automatically? If such a change makes sense, maybe I can attempt a PR for it.

[antonmedv]

With you have .mjs or .js editors will understand 😉

Also, mjs/js makes the distinction between ESM/CommonJS modules.

It's possible to add support for "empty extension", but I think the explicit extension is better.

[johantiden]

Concrete use case:

At my company we share a lot of tools. We put common scripts in a bin folder. These are written in the language most suitable for the task and it should be easy to replace these scripts with a new implementation as requirements change. Therefore, there can be no file extension in our script files.

The shebang should be plenty to go on for syntax highlighting. I respect that tooling isn't really there yet but it should be up to the users of this.

[tizee]

A quick workaround for this is that use a new shell script.

For example , assume that you've written a script called foo.mjs but you want to invoke it without extension i.e. foo. Then you could write a shell script called foo with content like this:

#!/usr/bin/env bash
zx /path/to/foo.mjs

Then put it into somewhere in your $PATH.
As far as I know, the mjs file extension is a must for Nodejs import statement. Here is the doc esm import specifiers .

[johantiden]

That would be nice! For me (and probably others) the temp files will most likely be exposed on the PATH, since the original file was exposed through it's containing folder. This will contaminate a lot of stuff, autocompletion, for instance.