Atom: Shebang in .ts (TypeScript) file causes it to render with .js (JavaScript) icon

[sompylasar]

[Alhadis]

Well... yeah, that's the expected behaviour.

Are you saying Node can directly execute TypeScript files without precompilation?

[sompylasar]

No, it cannot, but the shebang string gets propagated from the TS source to the JS compiled with tsc. If I omit it in the source, it won't appear in the output JS.

[Alhadis]

Ahhh, I see. Do you know if TypeScript-generated Node executables are common?

If not, I'd prefer to leave it as-is, and you can use one of the following solutions to override the icon locally:

1. Use your stylesheet

~less
.icon[data-name$=".ts"]::before{
font-family: file-icons;
content: "\2a6";
color: #6a9fb5;
}
~

2. Disable shebang recognition

Go to: Settings ⇒ Packages ⇒ file-icons ⇒ Match strategies and uncheck the second option:

3. Add a modeline

~~~js

!/usr/local/bin/node # -- TypeScript --

~~~
This works because modelines take priority over shebangs when determining which icon to use.

I actually don't recommend the third solution, since it's essentially a hack.

[sompylasar]

Match strategies looks the right way to go.

[sompylasar]

Do you know if TypeScript-generated Node executables are common?

TypeScript isn't yet common, so no, they aren't yet.

[Alhadis]

I see. Well, thanks for bringing this up. The package currently lacks heuristic support for icon-assignment (e.g., exceptions to the usual matching methods), but it may be worth adding in future. I'm sure there are other precompiled languages which work the same way as what you've described.

BTW, the hashbang will also affect the file's language classification on GitHub. You can actually fix it both here and in Atom by adding a .gitattributes file to your project:

~
integration-test.ts linguist-language=TypeScript
~

I actually recommend this instead, which I forgot about while writing out all that crap above...

[Alhadis]

@sompylasar I've made a unique exception for TypeScript files. This isn't something we normally do, but I've been unable to push this issue out of my head. Specifically, how ridiculous the workarounds are, and how common this scenario might become in future.

I should add that the reason I"m being conservative with icon-matching logic is because the routines responsible for mapping icons potentially run many thousands of times at once... the code needs to be as performant as possible. Hence why I've implemented this as an ad-hoc rule, instead of revising the config structure to accommodate precompilers.

[sompylasar]

@Alhadis Wow! Thanks :+1: