ES3/IE8/WSH incompatibility in core compiler code

[mihailik]

There is a delete member in one of the objects in createFileMap. See here:

113b7ed#diff-66cec844e251a1918deb897eabca206bR24

Delete is a keyword, not all JS engines can handle it. Specifically, ES3 spec seems to forbid it (ES5 being less strict).

Consider renaming to 'remove' and 'removeItem', plese.

Taking into account that this is the core of tsc, it's not good to limit the compatibility so. Compiler is still expected to work in ES3. IE8 fails to parse syntax { delete: deleteItem }, and so does Windows Script Host, which by the way is an official target for tsc to run on.

Here's a check page:

http://jsconsole.com/?var%20s%20%3D%20%7B%20delete%3A%20parseFloat%20%7D

Run on webpagetest:
http://www.webpagetest.org/result/150604_VP_CYC/

[danquirk]

Out of curiosity, where/why are you executing the compiler in an ES3 environment?

[mihailik]

That's fair. Before raising my voice to speak, I shoulda' got myself a Mac. Or Linux.

But my excuse is that my wife's become familiar with Windows, and don't want to migrate off.

What's yours?

[kitsonk]

That's fair. Before raising my voice to speak, I shoulda' got myself a Mac. Or Linux.

I think you are misunderstanding... The question is why are you trying to compile TypeScript "within" IE8? I think @danquirk is trying to figure out if there is a valid use case that he is missing as the compiler wasn't designed for that, but it can output code that works in an ES3 environment...

[mihailik]

I am humbled by the honour of explaining the basics of how TypeScript compiler works to the members of the compiler team.

Look at the link I have put in my message. It points right to the crux of the deal.

When tsc.js starts, the very first thing it does is it detects the environment type. For reading command line and accessing filesystem you know. There are two of them supported: WSH and node.js.

The latter is well-known, it's based on the industry-leading scripting engine from Google and enhanced by Joyent and nunerous efforts of the Open Source community. Quite rightly most of the folks from the street conflate node.js and JavaScript. Why on earth would one want to run tsc on anything but node!

Now the other, WSH.

WSH. Wi-SH.

Windows Scripting Host. Wish. Very obscure, corner-case technology. Only ever used by that quirky subset of people still in possession of what 's called 'Windows'. Hence the name. Windows Scripting Host. Have you heard of it? Wish. No, probably not. It's lost in centuries passed. In a galaxy far far away. Unreachable even by Tardis.

We may muse how the support for such antique technology managed to survive in a little pocket of tsc. Digital Terra Australis if you will. I fancy thinking it's Anders's secret joke on simpletons like you and me, and @danquirk perhaps? You may venture a guess it's a political concession to some important boss from the OS division whose heart is eternally attached to WSH, and whose support TS leads needed in the early stage of the project. We will probably never know. Every knowledge of that power sharing deal has perished, buried deeper than FIFA secrets.

Back to the subject. TypeScript clearly is committed to supporting no-node hosts. Or is it? In fact I am not sure. Let's pretend I never asked.

[RyanCavanaugh]

WSH is not an officially-supported host and never has been. If you've seen this written in some documentation, please tell us where so we can fix it.

The compiler code refers to things that look like WSH objects in the non-node codepath because we used to run on a hacked-up version of WSH internally. Externally, people should be using node.js or tsc.exe (which loads tschost.dll, which implements a set of interfaces that look like WSH but aren't).

We don't officially support any hosts other than node/io and tschost. That said, we're open to take PRs to add support for new hosts (e.g. #1789).

In terms of adding a new supported host environment, though, I don't see us supporting any ES3 runtime. ES5 predates TypeScript by several years and there's a limit to how much backporting we're going to do as new work.

[vladima]

btw, the original issue was fixed yesterday in #3383

[mihailik]

That's quite a lot more constructive, and VERY useful. Thanks a lot, @RyanCavanaugh for revealing this much detail, and @vladima for getting the project less wedded to a single platform.

ES3 compatibility did exist a while ago. Given that 99% of the code takes a great care avoiding anything smell8ng ES-like, it should be more or less mechanical to comb through the code and restore it to ES3 austere past. I hope I will find a few hours to play with that soon.

Besides, your explanation implies that tsc.exe lacks --watch support. I assume it's a historical flaw.

[RyanCavanaugh]

Re: --watch for tsc.exe, see #2375

[mihailik]

Closing per @vladima 's comment in #3383 .

[kitsonk]

I am humbled by the honour of explaining the basics of how TypeScript compiler works to the members of the compiler team.

Are you always this awkward @mihailik, or are you having a particularly off day?

[mihailik]

When I open an issue, I put in a good work to make it actionable and detailed. Deviations from this good will pattern are not appreciated.

[mihailik]

Just for historical completeness.

Currently tsc.js does work on WSH at least on simple files. More to it, it indeed works in IE8, IE7 and IE6 -- so long as the filesystem access is emulated.