Allow shebang in any file

[mk-pmb]

Rule details

I'd like to configure the shebang rule to do all of its regular checks, but not complain "This file needs no hashbang."

What type of rule is this?

Suggests an alternate way of doing something

Example code

#!/usr/bin/env -S nodemjs
import main from 'main.mjs';

main(process.argv.slice(2));

Participation

• I am willing to submit a pull request to implement this rule.

Additional comments

Also the message "This file needs no hashbang." should be a bit more helpful, rather than just patronizing. When I first got the error, my first thought was, "Of course it needs one, how else would my shell know how to run it?" So maybe let's change it to something like "This file contains a hashbang but is not listed as a bin entry in package.json."

[scagood]

There is an option in the rule for exactly this, it's called additionalExecutables

[mk-pmb]

Thanks! I assumed that empty array in the example is an array of glob patterns, so I expressed my intention "any" as '**' and that worked. Now instead I need a way to restrict the enforcement of executableMap to the files mentioned in the "bin" entry.
Edit: Or, even better, can I give a regexp of acceptable hashbang lines? (Edit 2: Nope. "Value {} should be string.")
Edit 3: Also This file needs shebang "#!/usr/bin/env node". should probably say "hashbang" instead of "shebang".
Edit 4: Turns out this is not a solution either. With '**', now all files are expected to have a shebang. I want to just allow it, not enforce needless shebangs.

[aladdin-add]

there are 2 options:

1. additionalExecutables: Mark files as executable that are not referenced by the package.json#bin property, default is [].
2. ignoreUnpublished : Allow for files that are not published to npm to be ignored by this rule, default is false.

[mk-pmb]

Neither of those work for me. I have scripts that are meant to be invoked by my node scripts, but would not usually be desirable to invoke from an interactive shell.

[aladdin-add]

I have scripts that are meant to be invoked by my node scripts, but would not usually be desirable to invoke from an interactive shell.

it seems an uncommon case; can you share an example to show how it's invoked in the node scripts?

[mk-pmb]

I salvaged the failed example from above by porting a simplified version of the CGI test from my other project. The test script uses cool node.js features (represented by encodeURIComponent) to construct a request for the CGI which uses cool node.js features (represented by decodeURIComponent) to parse its input.

[aladdin-add]

I see, thanks! you can safely disable the rule if your package.json does not contain pkg.bin field.

[aladdin-add]

1. the testing files don't have to be published: you can use pkg.files or .npmignore. https://docs.npmjs.com/cli/v10/configuring-npm/package-json/?v=true#files

2. If these files not to be published, you can use ignoreUnpublished: true, in which case none of these files will be reported.

[mk-pmb]

In the original project, the CGI is meant to be published because CGI is the preferred way to use the module.

[mk-pmb]

you can safely disable the rule if your package.json does not contain pkg.bin field.

The intent of my rules package is to avoid per-project rule definitions, so disabling the rule in every affected package would run counter to that. Disableing the entire rule would also disable all of its beneficial aspects. Could be a stopgap, but I hope we can do better.

Edit: I see now that you also wrote pkg.files above, so I assume you actually meant the bin field of my package.json. In that case it's void, because some of the CGIs are actually dual use for CLI and do have entries in the bin field.

[aladdin-add]

the files field is to configure which files will be published, please see: https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#files

[mk-pmb]

Yes, that is the field that I deduced you probably meant with pkg.files. I have the impression that we are on the same page about all facts now, and have a case where none of the supposed solutions above work.

If it helps for motivation, I could make a 1:1 example that includes the bin field entries, has various CGIs outside the test directory, and explains why it would be useful to have most of these CGIs published to npm. However, I assume everyone here has enough imagination that the current example will suffice.

In my eyes it's now about who wants to take the burden of adding and maintaining a rule for the requested feature.