Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Allow custom extensions (.ts .tsx .jsx)

See original GitHub issue

Pretty interesting proposal here: https://github.com/zeit/next.js/pull/2250/files#diff-0f2f34c098f5954f99483c9bd61e439dR51. We could reutilize this as a custom key in next.config.js to allow any file extension. Which also resolves the .jsx extension support 👍 talked about it with @arunoda 👌

Issue Analytics

State:
Created 6 years ago
Reactions:2
Comments:31 (7 by maintainers)

Top GitHub Comments

19reactions

D1nocommented, Aug 29, 2017

Hey @arunoda @timneutkens @nkzawa @rauchg , a friendly reminder that there is on open PR (https://github.com/zeit/next.js/pull/2699) to close this “help wanted” labeled ticket. Though it is labeled also as “nice to have”, not being able to use TypeScript prevents my company and two other open source projects to switch over to next.js.

It may be that you guys are not in a particular need for TypeScript, but searching this repository for typescript revels 31 related tickets alone. Excluding any jsx and extension tickets.

Me, including a broad band of the developer community, right up refuses to implement un-typed code. Especially if it is run universally on two or more infrastructures (server, browser, ios, android etc).

So I urge you guys to promote this ticket up in your priority chain and take a look at the sitting contribution. A few people have offered help already. Leveling off ecmascript variants (jsx, tsx, cl, etc.) is simply not a gimic. After that, next.js will defiantly become a go-to SSR solution.