fix(js/ts) fix detecting types as JSX

[joshgoebel]

Resolves #3276.

Changes

• adds a fallback default so when a confusing <....> block appears not to be JSX/HTML it's falls back to simply being ignored (by the JSX rule)
• this should prevent false positives of JSX blocks that effectively (and in some cases silently) break further highlighting - because they open but never close

Prior there was no fallback so if the common cases didn't classify the block it would DEFAULT to being HTML... where-as we really shouldn't consider something HTML unless it not only LOOKS like HTML but we can also find a closing tag.

I'm not sure the first conditional is needed at all now and think perhaps:

• If <blah is followed by > or space it MIGHT be HTML/JSX and we should search for a closing tag
• if not, then the JSX rule should ignore it

Checklist

• Added markup tests, or they don't apply here because...
• Updated the changelog at CHANGES.md

[joshgoebel]

I feel like this is ugly, but it does pass all test cases... ultimately this problem isn't really solvable (AFAIK) since we aren't a full contextual parser so I opted to do the simple thing that seems to fix the immediate reported issue.

[allejo]

👍 for working with nested types

[allejo]

Suggested change

	if (m = afterMatch.match(/^\s+extends\s+/)) {
	if ((m = afterMatch.match(/^\s+extends\s+/))) {

This is just personal preference and I don't know if we have more of these in the codebase, but I usually surround assignments in if statements with an extra set of () so that it signifies it's not a type for ==.

[joshgoebel]

Ugh, why is From and string there highlighted diff in your snap? Grr, it's HTML...

[joshgoebel]

Ugh, and if we don't flag it as HTML then we fall into the class "X extends Y" rule, which isn't really correct either... this may need more thought.