Discuss
  • Officially support a shebang line

Officially support a shebang line

# Jan Krems (8 years ago)

Tried to search past proposals for this but couldn't find one. The short version: Most editors / syntax highlighting engines, non-engine parsers, node.js - they all support a leading shebang line in .js files. With the advent of ES6 modules it's the final holdout where node has to patch the script source to make V8 parse the code (and thus producing a mismatch between what's on disk and what the engine sees).

Is there a downside to allow any script or module to begin with the magical #! bytes? It should not break existing scripts because it's invalid syntax today & the parse overhead should be fairly limited.

# Alexander Jones (8 years ago)

It doesn't make any sense. The shebang is a UNIX way of declaring the interpreter for an executable script, not for hinting your syntax highlighter. If your file is not executable (as in, it can't be run with ./filename, it shouldn't have a shebang).

# Jan Krems (8 years ago)

Sorry, mentioning support in syntax highlighters might have been misleading. I am talking specifically about executable JavaScript scripts and modules. It's a common pattern in node to have programs written in JavaScript, with a shebang and the x flag set.

I just mentioned editor / syntax highlighter support to say "this is already de-facto part of real life JavaScript as it's understood by tools, it's just missing from the spec".

# Wes Garland (8 years ago)

In gpsee (using spidermonkey), we allow executable programs exactly the same way as a shell script, and there is no real penalty from a JavaScript parsing POV. I'm not sure why node+v8 would be any different. We just hand over the script to the parser with the pointer pointing to the newline at the end of the shebang. This skips the syntax error and keeps the line numbers as expected. As Alexander Jones explains, this shebang support stuff is deep in unix, and arrives by virtue of the exec-and-friends system calls declared in unitstd.h.

I suppose the one 'gotcha' here is that you can't have a module which can both act as a program and library. We have the similar limitations in C - we have a special object file which has a symbol named 'main' and usually load library code as DSOs - but I never really found that to be a significant limitation in real-world work.

What is an example use-case that would take advantage of this proposal?

# Jan Krems (8 years ago)

What is an example use-case that would take advantage of this proposal?

There's quite a few scripts in "node land" that can be both entry point (executable) and library. The rough idea is:

#!/usr/bin/env node
function myLibraryFunction(filename) {}
module.exports = myLibraryFunction;
if (process.mainModule === module) {
  console.log(myLibraryFunction(process.argv[2]));
}

It's not that uncommon for languages with C-like comment syntax to have special support for shebang "comments" in the first line. Prior work includes:

For many other languages that can be used as executable scripts (*sh, Perl, PHP, Ruby, Python), the problem doesn't exist because they already allow # as line comments everywhere. Adding official support to JS would close a gap to most other scripting languages.