Add some way to specify a different output shebang

Suggestion

🔍 Search Terms

• shebang, hashbang, javascript, compiled shebang, #!/usr/bin/env node

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

TypeScript should offer some way to specify a shebang to be added to the top of the compiled JS file that is different to the one specified (or not) in the TS source.

For example, this TypeScript file:

#!/usr/bin/env tsx
//->#!/usr/bin/env node
...

would become:

#!/usr/bin/env node
...

📃 Motivating Example

Currently, if you want to create a file that should be an executable when compiled, you must place #!/usr/bin/env node in the TypeScript file if you want that at the top of the JavaScript file.

This is not ideal as the TypeScript file is then therefore classified as a Node executable / JavaScript file instead of TypeScript source code. It renders the TS shebang completely misleading as it should never be run with that executable.

• Related discussion can be found at at https://github.com/github/linguist/issues/5251

💻 Use Cases

The main use case is creating a Node CLI application in TypeScript. CLIs must be executables, so the outputted JS file must have #!/usr/bin/env node, which must also be found in the TS file, misclassifying it.

Extensions are just a suggestion; shebangs (usually) mean "execute me only with this", which should guarantee a language match. TS is forcing misuse of the shebang which should be changed.

L’issue non indica file, test o punti di ingresso. Inizia tracciando il modo in cui TypeScript gestisce gli shebang quando produce JavaScript e confronta gli esempi richiesti di TypeScript e dell’output. Il lavoro sarebbe completato quando fosse definito un meccanismo concordato per selezionare uno shebang di output diverso senza modificare il comportamento esistente.