Add a configuration flag to disable integrated type checker

[Timer]

Some users don't want to leverage Next.js' integrated type checking and prefer to do it manually.

While this reduces visibility during development, some users may prefer it.

This flag would only disable the forked type checking process (dev and build). tsconfig.json generation would still be mandatory.

---

Please provide a proposal before implementing this.

[timneutkens]

Just for reference I decided we need to allow this because there are cases where a company does tsc / eslint in a separate thread (eg with circleci workflows).

[fabb]

I‘d vote for not just allowing to toggle it on/off, but also pass custom settings, as it would be nice if eslint/tslint could be activated for the fork-ts-checker-plugin.
https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/master/README.md#eslint

[Janpot]

After thinking a bit more about my comment here, I've come to terms that this is a typescript issue and not a next.js issue. In case anyone is interested, there's a related ticket here: microsoft/TypeScript#13408. In short: typescript should be able to emit warnings instead of errors for linting errors.

[drewlustro]

I would also love to be able to turn this off in the name of compilation speed. Upon build, we run our code through tsc anyway, so it's not practical to have Next run type checking during each file edit.

[Timer]

@drewlustro Please note Next.js' TypeScript integration does not slow down compilation in any way. You'll see no speed benefits by turning it off.

[drewlustro]

@drewlustro Please note Next.js' TypeScript integration does not slow down compilation in any way. You'll see no speed benefits by turning it off.

I understand that, but it's presence still consumes CPU cycles on another thread, yes? My fans whirl a lot on Next 7. Next 9 is already a huge improvement, but I'm only trying to mitigate workstation load.

[Timer]

@drewlustro the type checking is fully incremental, so it's hardly noticeable after initial app boot.

[chrisblossom]

I'm very grateful the next.js team has decided to allow this to be disabled pending PR. I think the majority of these comments are off-topic and should be marked as such (including this one).

[chrisblossom]

This is a wild idea and probably belongs in its own issue. What if next.js had a browser addon that would display type / lint errors in a non-intrusive way (outside of the actual webpage, like redux-devtools-extension does) plus any other relevant information specific to next.js (such as if it is a static page), and toggle certain settings (such as this one).

I think this could further level-up next.js above their competition.

[Timer]

@chrisblossom please dump your thoughts in #8065

[chrisblossom]

@Timer is that what you had in mind? Please delete this comment if so

[jeremy-coleman]

here
https://github.com/jeremy-coleman/next-tsc-proposal/blob/master/start.js
gulp branch (my pref) also
https://github.com/jeremy-coleman/next-tsc-proposal/blob/gulp/gulpfile.js

that runs a prebuild step because im not letting next see my tsc files(this also fixes re-exporting types because babel doesn't see them). if you want an enterprise solution that supports typescript, you need to use typescript. Anyway, just try it out. I'm going to assume you know the differences and implications between typescript and babel output, if not please do ask

[kachkaev]

@Timer / @timneutkens will you accept a PR that adds this to Next config?

{
  typescript: {
    transpileOnly: true // same name as in ts-node --transpile-only
  }
}

There may be other ts-related options in future, so I'd prefer a nested value to, say, just skipTypescriptChecking: true.

It would roughly do what's described in #7687 (comment)

[timneutkens]

@kachkaev sounds good to me!

[kachkaev]

👀 #9138

[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.