next-typescript uses ts-loader again

[jagaapple]

Babel 7 supports TypeScript transpilation, Next.js 7 and latest next-typescript use Babel 7, but the limitation creates breaking changes.

On large project, developers create index.js (or index.ts ) to encapsulate the API calls from the web app into a single folder like the following.

// api.ts
export { ClassA } from "package-1";
import ClassB from "package-2";
import ClassC from "package-3";

export { ClassB, ClassC };

// main.ts
import { ClassA, ClassC } from "./api";

Babel 7 does not support these re-export types and throw some warnings. (For more detail: babel/babel#8361 (comment))

Currently, Next.js 7 block HMR when some warnings are shown (For more detail: vercel/next.js#5429). This means TypeScript developers creating index.ts cannot use HMR. Even if the HMR blocking issue is solved, Babel 7 throws re-export warnings.

So next-typescript should use ts-loader instead of Babel ( @babel/preset-typescript ) because ts-loader does not throw warnings and block HMR.

[DanHarman]

Yeah this is a pretty big limitation with the babel transpilation which I also hit, and they can't fix it. Would be nice to be able to choose whether to use ts-loader or babel.

[sorenhoyer]

Would this work for you?

// api.ts
export { ClassA } from "package-1";
export { default as ClassB } from 'package-2';
export { default as ClassC } from 'package-3';

// main.ts
import { ClassA, ClassC } from "./api";

[jagaapple]

@sorenhoyer It does not work...

[jagaapple]

To be possible to re-export some interfaces using next-typescript, should use ts-loader again, but I think it is difficult.
So I just created a package to use TypeScript using ts-loader with Next.js.

https://github.com/jagaapple/next-tsc

Thank you.

[drewlustro]

@jagaapple – cool workaround, but unfortunately that makes compilation take so long that the HMR client times out waiting for the hot update. Sigh.

[timneutkens]

Next.js will have typescript support by default soon.