Typescript `next dev` error reporting

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

[samwightt]

To be extremely clear about why this is so frustrating, let me spell out exactly what’s going on (as it still feels like there’s miscommunication):

The dev experience with only being able to run type-checking on build is quite poor. While builds are slow, that’s not the main pain point. The main pain point is that they don’t re-run on file change. When I introduce a type error into my project, it often takes me multiple type-checking runs to fix the issue. Fixing a Typescript error in one place often introduces a type error somewhere else due to my own carelessness, so I now am forced to run multiple builds (which again, do not re-run on file change, making the experience even slower) in order to make sure all type-checking bugs are caught before push.

Type checking in dev mode is standard behavior in nearly every other framework that offers Typescript support. Create React App works this way, Snowpack works this way, and I’m fairly sure Gatsby works this way. New users coming to Next from these frameworks expect Next to behave the same way. Users that are not aware of this behavior will discover this issue in their CI pipeline, which will fail at some point due to an uncaught error. Most newer developers will simply fix the issue, push the change back, and re-run the CI pipeline repeatedly because they do not understand how builds work. This is not only incredibly annoying, but also yet another thing people need to remember. Instead of just pushing changes to main when you’re done with a feature and have confirmed that it works, you now need to remember to run a (very slow) build locally (many times) so that you don’t waste valuable build minutes on a bug that could’ve been prevented in any other framework.

What makes this even worse is that this is a removed feature. This used to be standard behavior in Next, but it was removed due to performance reasons. Users have complained about this multiple times (see here for an issue comment with over 80 likes). Users would like an option that re-enables this behavior. They’re not asking for it to be the default behavior. They are completely aware of the fact that the core team does not think that this should be the default behavior, and they are fine with that. They are simply asking for this to be enable-able behind a feature flag. Unless there is some technical limitation that I’m not aware of, this should not be hard to implement (for instance, concurrent mode is currently hidden behind a feature flag).

Users are completely aware of the fact that this would slow down build times. Your users are not stupid. They know that adding in Typescript type-checking takes more time and would make fast refresh take more time to do its job. They are simply asking for the option to make that decision for themselves, instead of the core team unilaterally making that decision for them, forcing them to use hacks that do not have the same amount of polish that an official integration would have.

This is how your users are seeing things currently (again, to be extremely clear):

• User: Could you add back type checking in dev mode?
• Core team: Type checking was removed due to performance issues. It slowed down reloads by 10x.
• User: Great, I can deal with slower reloads if it means that my app is type checked during dev mode. However, I understand that not all users want this behavior and that the core team would likely not want to make this the default for all users. Could you re-introduce this removed feature as a feature flag so your users have the option to enable this at their convenience?
• Core team: Type checking was removed because of performance issues, and we will not introduce it again until someone creates an implementation of it that does not introduce performance issues. If you are able to create an implementation of this that doesn’t slow down rebuilds, then we will re-introduce it.
• User: Right, I completely understand that type checking slows down rebuilds. I do not care that it slows down rebuilds. I would like the option to re-enable it because the better dev experience of having type-checking on file change outweighs the cost of slower builds for me. Would you be willing to re-introduce this?
• Core team: Type checking was removed because of performance issues…

---

Because of this thread and several others, I’m currently going out of my way to explicitly tell people in my network (solo devs and team members alike) to avoid using Next and Vercel. The reason I’m doing this is not because of the poor dev experience here (although that is part of it), but because of the miscommunication and lack of listening to users from the core team here. Reread the bullet points above to understand what this is looking like from your users’ point of view.

The reason why I’m not recommending Next to people currently is not because of any technical issue, but because the core team’s inability to respond effectively to a basic feature request is, frankly, embarrassing. What if this were a more involved bug that was impacting people’s revenue? What if users had an issue with the framework that was causing outages, but when they opened an issue, it felt like they were being met with a wall (as users feel here)?

Please listen to your users. We are not idiots. This is an incredibly basic feature request, but the issues in communication here are a real problem and they should be resolved as well. I have a huge amount of respect for the work you’ve done here and the incredible framework you’ve built that is Next, but at the same time things like this are a very big problem that can impact a project’s long-term success.

[marten]

This is a major annoyance for me too. Disabling type checks because they’re slow seems ridiculous. If I didn’t want types, I’d be using plain Javascript rather than Typescript.

Disabling type checks means that NextJS can now quickly refresh with buggy code. I would very much prefer it being slower to emit working code.