Update list of TypeScript/JavaScript interpreters

[Alhadis]

@ahwayakchih's mention of Deno in #4469 reminded me that we haven't added it yet as a TypeScript/JavaScript interpreter, so here it is. Deno is a newer JavaScript runtime which has already gained traction for being a novel alternative to Node.js. It supports TypeScript out-of-the-box, making it a "true" dual JS/TS interpreter.

Template removed as it doesn't apply.

UPDATE: This PR's been updated to remove node from TypeScript's interpreters list as well, following conversation between @pchaigno and @grant. Merging this PR will now also fix #4469.

[pchaigno]

@Alhadis Could you add a sample file with that interpreter? If we remove the node interpreter for TypeScript, this sample file will become the only test of the changes we made to allow several languages to have the same interpreter.

[Alhadis]

@pchaigno Couldn't we just s/node/deno/ in the fixture's Hashbang? 😂

[pchaigno]

Oh, right, it's a fixture one, so yes!

[Alhadis]

I Deno if it was intentional or not, but the name "Deno" is an anagram of "Node". 😁

[ahwayakchih]

I'm not sure if that fixture makes sense for Deno. It's true that Deno is a TypeScript interpreter, but it does not have the same "core library" API as node, as far as i know. So things like call to require(), or importing fs or path may not work in Deno at all.
Maybe it would be better to replace current TypeScript fixture with true TypeScript, generic code? Like one of the examples on TypeScript website? So it would include TypeScript specific syntax, instead of looking just like regular JavaScript file.
Or maybe, for example, use https://github.com/angular/angular/blob/master/packages/router/src/router.ts instead? It seems to contain type declarations, type casting, and some other stuff that's not valid in "pure" JavaScript, so maybe it could be more helpful for the classifier than the current fixture?

[Alhadis]

This is a fixture file, it's only used for regression tests. The contents of test/fixtures aren't seen or used by the classifier, only the contents of samples are.

[ahwayakchih]

@Alhadis ah, my mistake, sorry and thanks for explanation :).

[pchaigno]

@Alhadis Could you also remove the node interpreter from TypeScript?

[Alhadis]

@pchaigno Done. 👍

[Alhadis]

@pchaigno Think now would be a good time to add other JS interpreters that we're missing?

JavaScript Engine	Name(s) of interpreter program
Chakra	chakra
SpiderMonkey	js
Rhino	rhino
V8	d8 (formerly v8-shell, v8, and then just d8)

Nothing "special" to any of these, they're just regular JS interpreters the same way Node.Js is.

[Alhadis]

@pchaigno Heh, I just discovered ts-node. 😉 Definitely going on the list.

Pretty much damning proof that adding plain node as a TypeScript interpreter was a mistake.

[qti3e]

This file is not valid in Deno. (mostly due to imports)

1. Deno is not Node so you can not import packages like 'fs'
2. The file extension is important (./x.ts is valid but ./x is not)
3. Deno does not use NPM, so import * as tsickle from 'tsickle'; is not right
   etc...

[Alhadis]

@pchaigno Could we get away with using a "Hello, world" type script for the TypeScript/JavaScript hashbang fixtures? I mean, the content of the script is kind of irrelevant after all...

[pchaigno]

Sure, but if it's not too difficult to find a sample Deno file, it's even better. It'd help train the classifier to recognize the few differences of Deno.

[Alhadis]

Ouch. Well, when I substitute the contents of test/fixtures/TypeScript/main for this TypeScript program, the tests fail, complaining that it identified as JavaScript. 😞

Do you think a heuristic is in order? Accurately differentiating TypeScript from JavaScript is impossible without a LOT of hairy regexes, but matching from "[^"]+\.ts" should work, since Node doesn't grok that extension.

[Alhadis]

I've pushed my update. Have a look at the test feedback, I'm not really sure what's going on... 😢

[lildude]

I'm not really sure what's going on... 😢

You do 😉 ...

Accurately differentiating TypeScript from JavaScript is impossible without a LOT of hairy regexes

You've added deno to both JS and TS so things will fall through to heuristics and then the classifier and as there isn't a heuristic we're falling through to the classifier which due to the similarities of JS and TS has guessed this is JS not TS:

$ LINGUIST_DEBUG=1 bundle exec bin/github-linguist test/fixtures/TypeScript/main
main: 66 lines (55 sloc)
  type:      Text
  mime type: text/plain
JavaScript =  -1455.108 +  -4.009 =  -1459.117
TypeScript =  -1591.191 +  -5.727 =  -1596.918
  language:  JavaScript
  appears to be a vendored file
$

[Alhadis]

Hold up. I thought the point of these fixtures was to assert that the interpreter directives were recognisable?

Not gonna lie, the tests are completely and utterly opaque to me. 😢 Really not familiar with unit-testing in Ruby, but this is what I'm used to reading.

so things will fall through to heuristics and then the classifier and as there isn't a heuristic we're falling through to the classifier which due to the similarities of JS and TS has guessed this is JS not TS:

Alrighty, sooo... the only sane solution is to remove Deno as a JavaScript interpreter. Which is okay, really, because TypeScript interpreters can compile JS, just not the other way around. 😁

[Alhadis]

It's my fault for thinking too much about file extensions being tested before heuristics... of course, hashbangs are most relevant in files that don't have any extensions.

I'm an idiot, sorry. Deno's been pushed back into TypeScript-land. 👍 Hopefully the specs will pass now...

[Alhadis]

Note that this is now blocking another TypeScript-related PR. Any chance we could get this wrapped up?

/cc @lildude @pchaigno

[lildude]

LGTM. Not sure if @pchaigno has any final comments or thoughts though.

[pchaigno]

LGTM!