Next.js: Typescript `next dev` error reporting

[keyworks]

Feature request

Describe the feature

When I run next dev and introduce a TypeScript type error on an active page, I expect to see a TypeScript error printed out in my terminal. This matches what the docs say:

By default, Next.js reports TypeScript errors during development for pages you are actively working on.

(From https://nextjs.org/docs/basic-features/typescript)

This works as expected in 9.3.6 but does not work in 9.4.0 or above. (I only tested 9.4 and 9.4.4)

To Reproduce

1. yarn create next-app
2. cd into app
3. Confirm you have next@~9.4 installed
4. mv pages/index.js pages/index.tsx
5. Introduce type error to pages/index.tsx like const x: string = 1234
6. yarn dev
7. Load / page and observe that there is no type error printed out.

Expected behavior

There should be type error printed out. This is what it looks like in 9.3.6 when I attempt to load the home page:

[ info ]  bundled successfully, waiting for typecheck results...
[ error ] ERROR in /home/jkim/code/my-app/pages/index.tsx(4,9):
4:9 Type '1234' is not assignable to type 'string'.
    2 |
    3 | export default function Home() {
  > 4 |   const x: string = 1234;
      |         ^
    5 |
    6 |   return (
    7 |     <div className="container">

System information

• OS: macOS
• Browser: Firefox
• Version of Next.js: Tested on 9.3.6, 9.4.0, 9.4.4. Bug found in 9.4.0 and 9.4.4.
• Version of Node.js: 10.16.3

[keyworks]

I just noticed the issue was changed from 'Bug' to 'Feature request'. But the documentation seems to imply it is already a feature.

By default, Next.js reports TypeScript errors during development for pages you are actively working on.

Does the documentation need to be updated?

[timneutkens]

Yeah the docs have to be updated, Next.js will only check types at next build as the typescript checker webpack plugin massively slowed down compilation.

[iOiurson]

Maybe add an opt-in option ?

[samwightt]

Seconded, an opt-in option would be very much appreciated. Being forced to run next build repeatedly to debug an error spread throughout the code base is not a very good development experience. It's cumbersome and very slow. I would love an option to type check on next dev, I'd take a slower reload time any day over repeated builds.

[samwightt]

Is there any update on this? It'd be really great if we had the option to do this. Create React App already has the ability to do this, I don't see why Next.js shouldn't have the same.

[timneutkens]

@samwightt you can read the reasoning here: https://github.com/vercel/next.js/pull/13428#issuecomment-634496718

If you can figure out a performant way to do type checking we'd be happy to merge it. The webpack plugin that CRA uses makes compilation 10x slower when you have typescript files.

[samwightt]

I don't really care if Next.JS build times are 10x slower in dev mode, that is my choice whether I enable that or not. Currently there is not even an option for me to do so, which is detrimental to the dev experience. It is incredibly annoying to have to do repeated next build commands to type check even a small app. I would gladly take a 10x slowdown in compilation speed if it meant that I didn't have to deal with my editor missing an error, deploying to production, having the build work for a few minutes and fail on a Typescript error. It makes me want to drop Next.js in favor of something like CRA.

This comment describes my experience perfectly. The PR that got closed looks like exactly the solution I need, but it's currently closed.

[timneutkens]

You can opt-in to that webpack plugin if you want to as you have access to the webpack configuration, it does not have to be a flag in Next.js. E.g. the PR is wrong nowadays given that we don't even have that webpack plugin in Next.js anymore as it caused a massive slowdown on builds as well.

Running next build to do type checking is not required. tsc --noEmit (typescript compiler in check mode) is enough to do type checking for example. However, ensure that you're on the latest version of Next.js given that we run typescript checking as the first thing in the build process now and nothing else is ran before that process finishes, making it the same speed as running tsc --noEmit (we practically do the same just at the start of the build process).

As said we'd be happy to bring this feature back if it runs as a side-process that does not hog resources and can be shown out of band. The webpack plugin does not work well for this case.

[pavlos256]

The new incremental compilation with noEmit can speed things up: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/#noemit-and-incremental

[samwightt]

Very disappointed to see that after two months this has still not been added despite this being a removed feature. Again, the option to be able to run TSC in a blocking way in dev mode (that's the user experience I want) is much better than the current solution, running next build repeatedly,. It's not a good dev experience and this really should be revisited.

An option for enabling the feature that was removed would be better than it just being removed.

[rokinsky]

I use this workaround in package.json with TypeScript 4 and incremental transpilation (speed is very good)

{
  "scripts": {
    "dev": "next dev",
    "dev:ts": "yarn dev & yarn ts:watch",
    "ts": "tsc --noEmit --incremental",
    "ts:watch": "yarn ts --watch"
  },
}