Compile TypeScript with Babel

[jstcki]

Since next.js v6 uses Babel 7, TypeScript can be compiled without ts-loader. Compilation should be considerably faster this way, especially in larger apps. Type checking still works with fork-ts-checker-webpack-plugin.

I've tested that this works but I'm not sure adding @babel/preset-typescript to defaultLoaders.babel.options.presets is safe to do. But it's the most convenient way without requiring users to add a custom .babelrc file.

This is a breaking change and should be a major bump (or rather minor to 0.2.0), since it depends on next@6 and removes typescriptLoaderOptions.

[jstcki]

@timneutkens Is there a way for the plugin to check for next.js v6? Because the upgrade error should be updated and thrown for versions below 6.

[timneutkens]

Lets have the user explicitly configure this in .babelrc, regardless of if they have one or not.

[jstcki]

I don't think that's very user-friendly … IMO it kind of defeats the purpose having a plugin when you have to

• install the plugin
• install @babel/preset-typescript
• add the plugin to next.config.js
• add a .babelrc

[timneutkens]

Lets keep this an array, otherwise I guess you could use loader as a key.

[timneutkens]

Actually we do it like this in Next's webpack config, so nevermind.

[timneutkens]

Lets have users install this too.

[timneutkens]

Actually I have a better idea to be backwards compatible in the future.

Lets create @zeit/next-typescript/babel (babel.js) which is a babel preset adding @babel/preset-typescript.

[jstcki]

Not sure what adding another preset would solve? It would just include @babel/preset-typescript, right?

[jstcki]

@timneutkens Thanks for looking at this.

Maybe it's not such a good idea to replace the existing plugin but probably it would be better to create a dedicated plugin since for some cases you'd still want to use ts-loader (since Babel can't transpile all TS).

Also, I think using the "new" plugin should be as easy as the current one, so I'm strongly against telling users to add a dependency and .babelrc in addition to using it.

I can change this PR to add a new official @zeit/next-babel-typescript plugin or I can publish it on my own. What do you think?

[timneutkens]

So the workflow I'd like to do is:

1. Install @zeit/next-typescript
2. Create next.config.js module.export = withTypescript()
3. Create .babelrc {"presets": ["next/babel", "@zeit/next-typescript/babel"]}

The reason for this is consistency between having a .babelrc and not having a .babelrc, since it's custom babel behaviour it makes sense to add a .babelrc, because right now you made not having a babelrc add a side effect that having a babelrc doesn't have, so you have to document it either way. The reason for the "custom preset" is also consistency and if anything changes in the future we can change things under the hood instead of having the users change the way it's configured.

[timneutkens]

Regarding

Maybe it's not such a good idea to replace the existing plugin but probably it would be better to create a dedicated plugin since for some cases you'd still want to use ts-loader (since Babel can't transpile all TS).

I don't think the caveats outweigh the gained performance. So I want to make next-typescript use the babel way, and if that's not enough for specific projects someone from the community could fork the older version and maintain it. Also this new version of next-typescript will be released as a major version (since the older one doesn't break in next 6 anyway).

[timneutkens]

Implemented everything mentioned above here: #171
Thank you very much for this pull request 🙏