(One possible reason to object: shebangs ought to refer to a file's actual contents, not the contents of a derived file. #!/usr/bin/env node is technically incorrect for LS files. Conversely, an LS script can correctly use #!/usr/bin/env lsc and be executable, but with this change if that file were also to be compiled, the output would have an incorrect shebang.)

For files intended to run with lsc, shebang should be:

#!/usr/bin/env lsc

But for files intended to be compiled with lsc and then run with node, the shebang line should be:

``#!/usr/bin/env node``

just like in example from #1030.
Why? Because it doesn't introduce any new syntax or exception to a rule.
Moreover, there wouldn't be incorrect shebangs left in files. The first example would strip the comment with an lsc shebang from the compiled file (correct), in the second example ``#! shouldn't be interpreted as a shebang (correct).

Flipping lines can stay, but I would rather test the compiled code for starting from #!.

@nazar-pc, what do you think about that? If

``#!/usr/bin/env node``
console.log 'Hello'

compiled by default to

#!/usr/bin/env node
// Generated by LiveScript 1.5.0
(function(){
  console.log('Hello');
}).call(this);

would that look good to you?

Having both support for running original script with LiveScript and compiled with Node directly seems highly unlikely, but still possible.

So if I understand correctly

#!/usr/bin/env lsc
``#!/usr/bin/env node``
console.log 'Hello'

would be still compiled by default to

#!/usr/bin/env node
// Generated by LiveScript 1.5.0
(function(){
  console.log('Hello');
}).call(this);

and work properly all the time.

I'm fine with that, makes perfect sense.

Found minor issue with this:

/**
 * Whatever
 */

is compiled to

/**
 * Whatever
 */
// Generated by LiveScript 1.5.0

instead of previous

// Generated by LiveScript 1.5.0
/**
 * Whatever
 */

GitHub seems to use this header for identifying whether *.js file is standalone or was compiled from other language like LiveScript and starts showing incorrect distribution of languages used by project.

Would you be so kind to fix this and add one more test case?

I'll look into it, thanks!