Guys need some help from someone knows typescript well to review this PR. :)
cc @impronunciable

@giladgray wrote in the other PR "this seems like an ideal minimal typescript example: it provides a clean solution for the single problem of typescript compilation". IMHO this is no longer a minimal TS example, this seems more like an example of Typescript AND Next.js, if you get the difference.

There is also some stuff that has been reverted from the "old" example, such as using a specific version for Next instead of using latest. Changing "target": "es2015" to "target": "es6" is also an odd one. Tsc has always transpiled TS to JS so I don't get the first sentence in the PR: "In typescript 2.2 it is now possible to compile to js." Are you referring to the use of "jsx": "react-native"? Why is that one being used? That option was introduced for compatibility with React Native’s loader.

There is quit some changes in the TS config file and package.json without adding any functionality. The only difference I can spot is the use of react-native, which would only require to update TS and change one line in the TS config file.

Sorry for being a bit harsh, I just want to bring along the context from the last PR where we spend almost 3 weeks discussing the example.

"This example [...] makes it easy to abandon typescript at anytime."

Interesting approach :)

@OskarKlintrot Exactly regarding "jsx": "react-native" before this the output was 'messy'. This combined with "target": "es6" makes the output exactly as you would/should write the next code yourself. (Thereby giving the user the option to at anytime say 'this is not worth it' and just delete the typescript library.
TS to JS yes, but not TSX to JS.

In my opinion the previous Typescript example was a bit too minimal :-/ so I just wanted to give a suggestion to how the folders could be arranged (typescript in one folder and output as usual (both form and folder structure) and show how to create React Element in Typescript.

So yes it is not minimal, but it will make fewer give up quickly (as I would have had I tried the current example when first trying out Typescript) The readability of the output is important (therefore the target es6).

I like this way because Typescript becomes an addon that can be so easyily added (without changes in webpack, babel etc) and you can just copy your existing js code in the tsx files and get the same js files! (plus warnings, autocomplete) and then you can start adding interfaces and parameter types to get even more intellisense.

(and I'll prefer harsh and honest any time ;-)

The only difference between "react-native" and "preserve" is that the file extension will be .js with "react-native" and .jsx with "preserve". To have JSX in a .js-file is a React Native thing, so "preserve" works just fine. You don't have to use JSX with React in the first place, some people prefer React "raw", so to speak.

"I just wanted to give a suggestion to how the folders could be arranged"
That's how you start a flame war :)

Dumping the build in the root isn't a) very pretty or b) compatible with assets. In something actually useful it's good to have the build separated to not bloat the code base or force the user to use something like VS Code but since you will probably need something like Gulp to move the assets we decided to keep everything minimal in the old PR. So this example is a bit bigger and showing off Typescript but is still not something that you will use to build your next Next.js app from. It's actually quit similar to what the old PR looked like in the beginning!

"So yes it is not minimal, but it will make fewer give up quickly (as I would have had I tried the current example when first trying out Typescript)"
If you want to learn Typescript then I think https://www.typescriptlang.org/ is the way to go, not the examples in Next.js.

"The readability of the output is important (therefore the target es6)."
The official name of es6 is es2015, that's why we used that value. The reason why you would want to use anything else than es5 is to be able to use for example babel than can take care of async/await that Typescript doesn't have (had?) support for. The readability of the output is not important, compare it to C# or C++.

"I like this way because Typescript becomes an addon that can be so easyily added (without changes in webpack, babel etc) and you can just copy your existing js code in the tsx files and get the same js files!"
Just as the old example if you would use the "preserve" option :)

Exactly - react-native is like preserve and rename which is exactly what we should want?

"If you want to learn Typescript then I think https://www.typescriptlang.org/ is the way to go, not the examples in Next.js."
In the other examples in the next examples folder they actually have examples of what it they're showing :) (server side rendering, preact, inferno etc)
Ant it is not learning typescript - it is using typescript with Reacnpm it.

"The readability of the output is not important, compare it to C# or C++."
I disagree - next has the build part covered. We just need to compile to es6 and let next do it's magic.
That's why it's ok using the root is ok - the typescript folder only has typescript otherwise the project is as if we just wrote normal next code.
Furthermore if you need help with some code you wrote it is now possible to just post the compiled js code to stackoverflow (they don't need to see the tsx code) in the previous example you would have to post typescript or something like
const React = require("react"); const MyComponent_1 = require("../components/MyComponent"); exports.default = () => React.createElement("div", null, React.createElement("h1", null, "Hello world"), React.createElement(MyComponent_1.default, null));

yes Typescript has async await support.
"In something actually useful it's good to have the build separated to not bloat the code base or force the user to use something like VS Code but since you will probably need something like Gulp to move the assets we decided to keep everything minimal in the old PR. "
Exactly - don't bloat the source folder with tsx files. Use a different folder for the source and have Typescript rename files while compiling them into where they should be.

Extra point - the old way relied on Typescript's conversion to React. This way is better. (again yes - preserve will do the same)

To me it seems as if the only thing you really want to change is "jsx": "react-native" (or preserve) to be able to post the built code on SO. To be honest this PR just feels as if it is adding a lot of opinion based stuff that we already stripped out of the example.

Well and update the example so it actually worked (react and react-dom is missing from package.json)
And add an example of a react component so that this example would resemble the others in the example folder.
And the way modules are handled. (which is necessary to have the out look like normal code)

Proposal:
I remove the folder structure part but keep the typescript files (with React components)
(Actually the previous example had 2 tsx files - just not any React components...)

If so, should I change to next:latest in package.json? (thereby risking it suddenly won't work (as happened with current example))

"..to be able to post the built code on SO" more importantly keep the separation:
Next compiles to React.
Typescript does it thing and changes very little in compilation. (just removes the declarations)

Thereby keeping the modern trend of taking the best of many easily replaceable/removable parts.

And I don't understand why you don't want a React component (you already have 2 tsx files in the example)

"Thereby keeping the modern trend of taking the best of many easily replaceable/removable parts."
Exactly, that was my point above when talking about Babel/async/await/ES2015.

"And I don't understand why you don't want a React component (you already have 2 tsx files in the example)"
Don't I? The old example didn't have any state and then the docs recommends to use stateless components/functions. In this PR the one without any state can be converted into a stateless function as well. What I want is a completely different story, I'm just trying to keep the context from the previous discussion about why the example looks like it does. If it was down to me it would be a full blown production ready example application :)

:)
I think I know what to do - I'll close this PR and build a new one without opinions, but it will be great.
(It may even defeat ISIS in 30 days ;-)

Best comment ever on a PR! 😃

Looking forward to the next PR! :)

this is also a pretty substantial rewrite of the typescript example that introduces some patterns i've never seen before. do you have to change everything or can you just do the minimal upgrade to 2.2.?

edit and now i see the full thread. thanks @OskarKlintrot for saying all the things i would have said.

#1610