Allow JSX without using .tsx extension

[sindresorhus]

Search Terms

JSX, TSX, React, extension

Suggestion

I'm creating a new issue because comments in the closed #26489 issue are ignored, but it's clear that many people want this.

It's annoying having to use a separate file extension just because you want to use JSX. Not all tooling supports the .tsx extension. It also means you either need to always use .tsx if there's a possibility of JSX usage or you need to keep renaming files when you add JSX to them. Neither are good UX.

I propose deprecating <Type>expr in favor of as (as suggested in #26489 (comment)). They do the same thing, but as is not conflicting with JSX. No point in having duplicate syntax that does the same thing.

Alternatively, add a compiler flag to disable <Type>expr, which means JSX could be supported for the .ts extension when this compiler flag is used.

Use Cases

Examples

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[bricss]

Please don't. For a instance 👉 airbnb/javascript#1235 (comment)

[sindresorhus]

@bricss This is different. TypeScript (and .ts) is already "non-standard" in the JS sense.

It also doesn't reflect most JSX users opinion about .jsx vs .js. See: airbnb/javascript#985 (comment) (Look at the votes)

---

The argument from airbnb/javascript#1235 (comment) is:

essentially, .js should only ever be for files that use features of standard JavaScript

But JSX is part of TypeScript. So that argument falls apart in this case.

[DanielRosenwasser]

Not all tooling supports the .tsx extension.

A world where half the tools can't figure out what the right way to parse a .ts file on its own is so clearly worse to me than the current world. I'm curious as to what tools can't support .tsx files and why.

[dragomirtitian]

@sindresorhus <> assertions are not the only parsing ambiguity. Generic arrow functions also behave differently in .ts vs .tsx:

let fn = <T>(o: T)=> o; // ok in ts parsing error in tsx, <T> is the start of a tag

[sindresorhus]

A world where half the tools can't figure out what the right way to parse a .ts file on its own is so clearly worse to me than the current world. I'm curious as to what tools can't support .tsx files and why.

The cases I've seen are simply that they only considered the .ts extension.

[sindresorhus]

<> assertions are not the only parsing ambiguity. Generic arrow functions also behave differently in .ts vs .tsx:

IMHO, that should be solved regardless of the outcome of this issue. Even with separate extensions, it's weird that TS and TSX works differently in common cases like this. I don't have a solution. I'm hoping smarter people than me can come up with one.

[donaldpipowitch]

Probably a duplicate of #8529. At least that's what I originally wanted as well (but the discussion drifted a little bit away and the title was changed from Make ".tsx" extension optional to Make default JSX mode "react" ). So I'm glad this topic is raised again. Thank you.

[hax]

I think the key problem is <jsx>...</jsx> do not have definite semantic as general purpose language. (compile to React.createElement() is too domain-specific, framework-specific) So it's hard to imagine how jsx could be a part of js standard. This is also apply to TS.

Of coz, there is another problem, whether we allow non-standard feature in .js or .ts extension. Strictly speaking, many .js files today are using "babel language", not js language 😂 (and babel now support almost all TS syntax too 😘). But such issue is always not a solely tech issue, but a social issue. Remember there are many programmers dislike jsx anyway 😅 and don't want jsx "pollute" their js source codes.

[dragomirtitian]

@sindresorhus I think smart people did think about this and they did not leave this in because of laziness.

The ambiguity is not easy so solve without looking a lot ahead into the stream trying to interpret <T>(o: T)=> o; as the start of a tag and if that errs, try interpreting as a generic function .. or the other way around ... But either way performance would suffer in both cases.

[Schniz]

@hax

compile to React.createElement() is too domain-specific, framework-specific

I agree that compiling to React.createElement is too specific, but supporting JSX isn't just for supporting React. It'd be totally acceptable that I would need to configure what JSX will be compiled for, and I will get an error if it wasn't configured.

.tsx already exists, so there's nothing new here, just unifying the experience. And it doesn't mean tying everything to React!

[pavan-shipmnts]

Since I use .js for all react components it's very natural to use .ts and why can't ts compiler support both .ts and .tsx.

[OctoD]

It could be enabled with a flag (maybe a tsxExtension).

By the way, I do not think that enabling and forcing this by default could be a good idea: people developing batch, command line interfaces or back end stuff should not have the risk of outputting jsx related stuff.

[mathiasbynens]

This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)

It seems this box shouldn’t be checked.

[sindresorhus]

@mathiasbynens By default, TypeScript doesn't transform the JSX, so it is correct.

[weswigham]

FYI, most editors also need different grammars for syntax highlighting tsx vs ts (because of the aforementioned ambiguities) and key which to use off of the extension by default. For every tool that doesn't work with .tsx there is, at this point, another tool which wouldn't work without .tsx. I'm not the biggest fan of semantic extensions, but it is a workable solution to the ambiguity issue.

[niieani]

@weswigham I think the point of the issue is that we wouldn't need different grammars if we dropped the ambiguities. Flow does not have the <number>expr casting syntax and it handles lambda functions with generics const x = <T>() => <div></div> without issues and alongside React components.

[DanielRosenwasser]

But you're not dropping any ambiguities with this proposal (since .ts already doesn't permit JSX), you're just introducing them.

[weswigham]

For your consideration:

let fn = <T>(o: T)=> o;
1 < / T >, o // 2

The above code is syntactically valid TS, and, except for the type parameter and annotation on the lambda, syntactically valid JS. In flow, the above code is also valid... but not like you'd think based on the indentations. <T> is interpreted as a JSX opening tag, which is closed on the following line with some text, followed by a comma indicating a second let variable with no initializer followed by a comment.

flow still has the ambiguity - rather than issuing an error, they just greedily assume <T> is a tag if there's a token sequence that can provide a matching end tag (I can't really fault this as there are other ambiguities where we do something similar; but the ambiguity is part of our justification here). There is no "correct" way to parse the above sequence of tokens in the context of JSX. Outside of JSX mode, TS correctly parses this - <T> is a type parameter list, and the second line is "1 less than some regex literal containing 'T>,o' divided by 2" (strange to write, but syntactically valid code). In JSX mode, we usually issue an error on the <T> because we know it's potentially ambiguous, as in this example.

[niieani]

I wasn't aware of this, great example @weswigham, thank you!
Would it be any less ambiguous if there was a hard requirement on JSX tags in .ts files to be wrapped in braces (like prettier does by default)?

const jsxInDotTs = (<span>
  hello
</span>)

An extra brace is still better than not having JSX in .ts at all :)

[RyanCavanaugh]

Please don't open new issues because you didn't like the outcome of prior issues; we cannot sustain a repo where every declined issue just gets re-filed. We read comments in closed issues and are happy to hear additional feedback in #26489