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.