Typescript `next dev` error reporting
See original GitHub issueFeature 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
yarn create next-app
- cd into app
- Confirm you have
next@~9.4
installed mv pages/index.js pages/index.tsx
- Introduce type error to
pages/index.tsx
likeconst x: string = 1234
yarn dev
- 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
Issue Analytics
- State:
- Created 3 years ago
- Reactions:23
- Comments:32 (6 by maintainers)
Top Results From Across the Web
Typescript next dev error reporting #33634 - GitHub
By default, Next.js reports TypeScript errors during development for pages you are actively working on. Does the documentation need to be updated?
Read more >Advanced Features: Error Handling - Next.js
Error Handling. This documentation explains how you can handle development, server-side, and client-side errors. Handling Errors in Development.
Read more >Catch TypeScript Errors in Next.js Before Building Your App
This command will catch JavaScript errors according to your ESLint configuration, but the ESLint configuration is not automatically aware of TypeScript, even ...
Read more >Build errors in my next.js app after upgrading to 12.#.# and ...
I needed to run yarn add --dev @typescript-eslint/parser @typescript-eslint/eslint-plugin. and add this to eslintrc.js.
Read more >Next.js API routes - Global Error Handling and Clean Code ...
No conventions for handling API errors. This is a problem because we want to handle errors in a consistent way (so that we...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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):
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.
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.