Opting out of typescript checks in Next 9.0+

Feature request

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

In Next.js <= 8.1.1 we’ve been using @zeit/next-typescript, which essentially meant passing ts and tsx files through @babel/preset-typescript. Because of that, imperfections in typings did not prevent the dev server from refreshing or the production app from building. That felt like a convenient DX, given that proper ts checks could be done via yarn lint:tsc in CI (this script would call tsc --noEmit).

I’ve been playing with the latest canary (<= 8.8.1-canary.61) in a couple of new projects and noticed a change in the DX, which I found somewhat distracting. Because TypeScript compiler is now continuously used during development, even a slightest type-related imperfection crashes the app.

The problem with this approach is that it is much harder to experiment with the new stuff. E.g. I can’t create a new component, then call it somewhere as <NewComponent foo={data} bar={42} /> and only then implement the typings for the props and handle them. Redundant props are detected by tsc as soon as I mention them, which prevents the app from refreshing. That locks the development process into a certain sequences of steps, which don’t always feel natural.

Given that I can run yarn lint:tsc separately, I don’t even mind being able to next build in spite of type-related imperfections, as long as the produced JavaScript is sane. This can be useful, for example, when deploying a preview app for a PR that has not been finished yet (the new functionality works, but typings still need a bit of polishing).

Describe the solution you’d like

I understand the motivation behind the new way of tracking TS errors. If I remember correctly, create-react-app does the same. Crashing at each TypeScript imperfection can indeed be useful. For example, it won’t let newcomers do the wrong thing and won’t overload them with the notion of different kinds of errors.

However, some developers like myself will probably like to avoid tsc-related crashes both during next dev and next build and just rely on yarn lint:tsc as before. Not only this will make experimentation less painful, but also ease project migration into Next.js. We have a few non-Next.js React projects containing a mix of ts and js files. Renaming *.js to *.ts creates quite a few tsc errors, which can’t be fixed in one go. The only option is to ensure each new PR does not increase the number of tsc errors until zero is reached.

How feasible would it be to implement a flag in next.config.js? Something like:

module.exports = {
    skipTypescriptChecking: true
    // or
    typescript: {
       transpileOnly: true // same as ts-node --transpile-only
    }
}

Seems like with the flag like that there’s even no need to create tsconfig.json. Next app can sit in a yarn workspace inside a monorepo, where yarn lint:tsc uses a manually crafted top-level tsconfig.json.

Describe alternatives you’ve considered

Using a stable Next.js release (8.1.1) works well, but it won’t be the latest framework version forever.

Additional context

• This issue is the reverse of https://github.com/zeit/next.js/issues/6466
• This issue is created out of this comment I left a couple of months back: https://github.com/zeit/next.js/issues/7114#issuecomment-485748729

[callumlocke]

@Timer please reconsider your position on this.

I’m not sure if we want to give users the easy control to opt-out of type-checking

Just to reassure you, no one here is trying to to “opt out of type-checking”, otherwise we’d just switch to plain JavaScript! We just want to opt out of type-checking during the Next build.

I think it’s great that you offer a simple way to fail the Next build on type errors, for the many users who still prefer that behaviour. And I don’t even mind that it’s the default. But it is frustrating that you don’t trust our judgement when we want to opt out of it. Our preferred workflow is no less rigorous or valid. We just enforce type-checking at a different point in the lifecycle, along with our unit tests and linters. Some teams enforce it as a pre-commit hook, others enforce it as a PR merge condition or during a CI deployment job.

[dmitweb]

@kachkaev it may helps u, i use this in canary version my project from the first version next with ts

    config.plugins = config.plugins.filter(plugin => {
      if (plugin.constructor.name === 'ForkTsCheckerWebpackPlugin') return false;
      return true;
    });