Typescript: Support html-style comments

[bterlson]

TypeScript Version: 1.8.0

Code

<!-- console.log(1) -->

Expected behavior:
The ECMAScript spec defines HTML-style comments that are allowed in scripts, so the above script is syntactically valid. This syntax is allowed in browsers and Node.

Actual behavior:
Syntax error.

[nojvek]

Not sure if the typescript core team will pick this up but should be a nice PR if anyone wants to take a stab at it.

[yahiko00]

Interesting.

[DanielRosenwasser]

I think we'd be willing to take a PR but I'll let this get triaged first.

[RyanCavanaugh]

This is blocking me from adopting TypeScript

Edit: @yortus had a good idea about downleveling. I think this should be the default, with a --noEmit<!---->Comments flag for those who want to retain lame-style (//, /*) comments.

[yortus]

@RyanCavanaugh would you consider switching to TypeScript if it allowed you to cast to HTML style by writing /* a comment */ as HTMLComment and it downlevelled this to <!-- a comment --> in your JS output?

[mhegazy]

Reference to the spec: http://www.ecma-international.org/ecma-262/6.0/#sec-html-like-comments

one note, it is not supported when parsing modules.

[yahiko00]

I am wondering why they felt the need to _extends_ the comment syntax...

[mhegazy]

From Annex B in the spec (emphasis mine).

This annex describes various legacy features and other characteristics of web browser based ECMAScript implementations. All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification. However, the usage of these features by large numbers of existing web pages means that web browsers must continue to support them. The specifications in this annex defined the requirements for interoperable implementations of these legacy features.

These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.

[bterlson]

@mhegazy: Good point about modules - I missed that in my earlier reading. I guess that drops the severity of this issue from super severe to just pretty severe, right?

[mhegazy]

:D

[DanielRosenwasser]

ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.

Then let's not even accept PRs on this. New implementations are discouraged from implementing this type of comment.

[mhegazy]

For TS i would agree, but we do use our parser as a JS parser, even for script blocks in HTML. for that we should accept the html comments, and parse them correctly. failing to do that, prohibits us from correctly parsing, and thus providing any LS features, in script blocks with an html-style comments.

[RyanCavanaugh]

But it's code that may not even run in newer browser implementations. It seems preferable to just error, especially since we've never heard of anyone doing this on purpose.

[mhegazy]

it is an error in a module, and should be reported as such. but should be parsed correctly as well, even if we report an error. this allows for a better error message, and better error recovery. this is similar to how we handle the git conflict markers for instance. thought this is arguably part of the language.

as noted, we would accept a PR for this. i do not think the core team would commit to taking it on unless we get additional user feedback.

[bterlson]

FWIW, this code is still required to run code on the internet, mostly legacy scripts of the form:

<script>
<!--
alert(1);
-->
</script>

so new browser implementations would have to either implement this syntax or throw errors on a non-insignificant number of websites.

[bterlson]

Also worth noting that there is some disagreement within TC39 about whether Annex B is really optional in any sense. For example, why wouldn't Node want to run code designed to run in web browsers? An argument can be made it's just a way for the committee to feel good about putting bad but necessary features in a different place. And in practice, Annex B seems to be implemented everywhere.