Ability to opt-out of Babel based Typescript support and use the original Typescript compiler

[zetoke]

Feature request

Ability to opt-out of Babel based Typescript support and use the original Typescript compiler

Is your feature request related to a problem? Please describe.

Yes, it's related to problems because Babel Typescript plugin isn't fully featured and does not support all the features of Typescript and has multiple caveats (e.g. with types re-exporting or .d.ts files for styles with export =).

Describe the solution you'd like

• Have an ability to turn off automatic .ts/tsx/d.ts files transpiling by Babel in the Nextjs config file.
• Have an ability to plug in Typescript original compiler in the development flow (e.g. use separate plugin the will modify a webpack config). (Will the old version of next-typescript plugin work?)

Describe alternatives you've considered

Not sure about alternatives in this particular case. But I'm open for ideas!

Additional context

n/a for now

Has not found any other issues with such specific request so created a new one.

I'm very happy to see the progress that you folks are doing with Nextjs! Especially cool to see a huge library of examples.
I'm volunteering and would be really happy help with this features somehow or to create an example and write a documentation. But does not have a huge knowledge about Nextjs internals :(

[timneutkens]

So the reason that we don't use tsc is that it would introduce significant slowdowns and issues with optimization, especially with new upcoming features like module/nomodule (modern JavaScript output) we don't have enough control over the tsc output, but we do have control over the babel output (with or without TypeScript).

[zetoke]

@timneutkens ok. By slowdowns you mean build times during development and doing production builds, right?

[timneutkens]

Build times in development and production, which is a tradeoff you don't want to make in general.

[Janpot]

(e.g. with types re-exporting or .d.ts files for styles with export =)

@zetoke What are these issues? Do tickets for these exist in the babel repo?

[zetoke]

@Janpot

The first one

Does not support export = and import =, because those cannot be compiled to ES.next.

this one presented in items from officially described caveats/problems list in the documentation of the transformer https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats and will not be fixed I think. With other stuff in this list.

The second one exists in Nextjs issues #7882

It's only a couple of examples. Of course I don't use all the features and will probably not see other problems since I don't use all the features of Typescript usually but I just worry that I can't write valid Typescript without keeping in mind all the constraints of Babel's Typescript transformer (and this is a big list!) and need to google and find workarounds for already existent projects.

And I just think if there would an ability to opt out I can use incremental builds from Typescript 3.6 without big drop offs in build performance for development purposes.

Thank you guys for the very quick answers here!

cc @timneutkens

[timneutkens]

We're not planning to change this at this point in time.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.