Allow custom extensions (.ts .tsx .jsx)

[timneutkens]

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 👌

[timneutkens]

@berzniz I'm going to look into this RN 👍

[berzniz]

I also started working on this (with unit and integration tests), but hit a wall where I can not import jsx files with:

import Test from './test`

but can do it with

import Test from './test.jsx`

Here's what I have so far:
berzniz@ee055e9

[timneutkens]

Cool thanks @berzniz ❤️

[nelak]

@berzniz Don't forget to change server/utils.js for hot-loader support
I'll try to remember the other tricks I used to get this working :)

[nelak]

@berzniz I think what allowed me to do the imports without extensions is that I'm emitting all the files as .js with the emit-file-loader. You can give that a try.

[kdby-io]

#2250

[berzniz]

That's great! Totally helps solve the problem

[arunoda]

@berzniz adding .jsx support is not what we meant here.
We only support .js by default.
But users can add .jsx, .ts or any extension they want as need.

[berzniz]

I see. I'm just providing what I got so far, so someone can mix it with a configurable array of extensions. I'm probably not the person to tackle that (at least not for my first PR)

[arunoda]

@berzniz thanks for the PR.
Yep. I might do it after 3.0

We have a lot of great stuff in 3.0 and we wanna ship it ASAP.

[nelak]

@timneutkens Initially I was thinking of moving the glob matches and the other configs to the default config so they can be overwritten with a custom next.config.js, the only caveat of why I didn't do this was that the config would need to be referenced from other places besides webpack.js
If you can provide some guidelines on how you want this to be solved I can improve on my initial PR.
Let me know and I'll be happy to help

[D1no]

Hey everyone — what is the velocity on this? I would love to use next.js on an open source project together with (typestyle)[http://typestyle.io/] to generate static, github pages hostable content.

This seems to be a nice combination given the static export option and typestyles ability to hoist all css classes. (just an example: egghead > "Generate static css + html files using TypeStyle")

[D1no]

Congrats to the new release!

[srghma]

Why so long((

[D1no]

Could you guys please merge #2699 to close this ? Thanks...

[D1no]

Hey @arunoda @timneutkens @nkzawa @rauchg , a friendly reminder that there is on open PR (#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.

Thank you for the great work you have put into this project. I am excited what comes next to next.js — all that beyond this corner issue.

Best
Dino

[timneutkens]

@D1no I'm going to have a look at it soon. There's 42 open PRs RN and I have to review most of them. This one is not a small change I can merge in instantly, I'll have to test it thoroughly to make sure nothing breaks 👌

[D1no]

Yeah I understand. You guys are getting pupular 🤗 Thank you for jumping in

[D1no]

@berzniz @gloorx @kylefinley @Rokt33r @mmmeff @stiliankanchev @bangonkali @HyunSeob @lambrojos @stushurik @Fowowski
Since this is dead, go checkout static-react — we're looking into bringing a very modular and reacty typescript implementation to life: react-static/react-static#8

Contributions are very welcome !

[pie6k]

Any update?

[thealjey]

How about *.mjs? Why not just have a config option that would allow people to configure any number of extensions to be treated as javascript?

[rosskevin]

I'm trying to switch material-ui over incrementally to Typescript mui/material-ui#9535 and this is a blocker because material-ui uses next.js for docs.

I have material-ui (combination of js and ts/tsx files during transition) building with babel 7.x (and webpack) and I do not need to use ts-loader etc. I just merely make the webpack config aware of the extensions:

  module: {
    loaders: [
      {
        test: /\.(j|t)sx?$/,
        loader: 'babel-loader',
        exclude: /(node_modules)/,
        query: {
          cacheDirectory: true,
        },
      },
    ],
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
  },

I'm new here so please be gentle. What rationale prevents next.js from doing the same and simply using /\.(j|t)sx?$/ to allow js|ts|jsx|tsx extensions to be processed? I'll keep looking... (but I'm confused).

If I submit a PR will this one be accepted?

[lednhatkhanh]

@rosskevin Please go ahead, I'm also facing this problem when trying to integrate typescript preset to babel

[D1no]

@rosskevin I really love material-ui. Would you maybe like to check out react-static (https://github.com/nozzle/react-static)? I wanted to do a material-ui example for a while - I also love TypeScript - so there would be e few things falling together, as I would love to see material-ui migrate to ts.

React static has a few advantages

• it is pure React (v16) with React Router
• therefore the custome layer that generates static pages that could be hosted from i.e. github pages is very very thin
• meaning, react static focuses on speed and seo while carrying over the deeply tested functionality of standard react tools.
• If you want to costumize or add something, you can always extend the webpack config easily (take a look at ‘static.config.js’: https://github.com/nozzle/react-static/tree/master/examples/typescript)

https://github.com/nozzle/react-static/tree/master/examples/typescript

• The TypeScript example I have added to React static supports incremental JavaScript and TypeScipt (so legacy js and new ts files can be mixed and referenced by each others - great for adapting TypeScript gradually), incl hot module replacement, path aliases via the tsconfig.json and all top level features of TypeScript you would expect without a pre-compile / build folders of an intermediate js step. It’s very fast.

Join the react static slack channel or see the history; we are very active.

[ifiokjr]

This looks like it would be perfect for adding TypeScript support!

My team is starting out on a new project and have heard great things about next.js for universal applications. I'm slightly surprised that the TypeScript support isn't there especially with several PR's which seem to solve the issues.

I haven't had much time to look through the next.js codebase, but from the PR's I've seen the code changes don't seem overly impactful. Perhaps I'm wrong.

Is it worthwhile adopting next.js or should we assume that TypeScript is not in the roadmap and decide between creating our own SSR for React apps or looking elsewhere?

[D1no]

@ifiokjr May I ask why you‘re waiting for next to move instead of using react-static or any of the other TypeScript supported static site generators?

[srghma]

@D1no, not all features of next.js accessible in react-static.
There is still no example how to make SSR with react-apollo.

I have tried to do this, but I need request url in static.config.js and I don't know how to get it.

P.S.
I bet that my approach is bad, it's not clear how this will behave on react-static build.

[D1no]

Well, its plain apollo. You would need to use its optimistic ui feature or its hydration feature. But since it’s GraphQL, I‘d suggest you try gatsby instead. Its build around GraphQL: https://github.com/gatsbyjs/gatsby

react-static is really about the native react way. So there is not much magic by intention - and inside of the static.config.js you can make all the calls and setup for the static site as you please. However, it requires you to use your libraries features.

[rosskevin]

@D1no Please stop promoting/supporting react-static in a next.js issue. Thank you for letting us know the alternative, now I'd like to remain subscribed to the subject at hand - next.js and typescript.

[D1no]

Sorry @rosskevin, but you follow the wrong rail. react-static is a result or artifact of this issue not moving forward. And as this is Open Source, and react-static an intended solution for server side rendered TypeScript based React projects, filling this gab within the next.js toolset is more than appropriate to point out. Therefore, if you look at my constant involvement in this and other issues related to TS in next, that — what you call promotion — is a pin point answer to the question/problem at hand.

If you happen to run blind reading about implementation and solution paths, unfollow this thread and create a new one that deals with implementing a parity to something we have put a lot of work in. Both in issues and neglected PRs to next and react-static as a singelton implementation (not excluding other static site generators).

If aunda et. al. have time and interest to mirror behavior, we‘re all happy to help (seen often above). But for the time beeing, out of scope and implemented else where

[timneutkens]

I'm going to lock the conversation since I'm working on a solution and the scope of the issues is not being discussed anymore.