Allow use without a file extension

[rattrayalex]

I'd love to be able to use zx scripts without a file extension (like $ ./dev instead of $ ./dev.mjs), still with top-level await. I'm not sure what would be required to make that happen, but the readme today says you need the extension.

I'm also not sure whether common editors like VS Code or Github recognize the zx shebang for syntax highlighting as .mjs javascript.

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

[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]

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

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

[antonmedv]

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

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

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

[reggi]

#!/usr/bin/env npx zx 1) enables syntax highlight for js 2) also downloads zx if it's not available