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.

[bleucitron]

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: #13428 (comment)

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"
  },
}

[vhakulinen]

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.

Would running tsc in another process acceptable solution? FWIW, typescript (the compiler) is slow and there really isn't any way around it unless you want to work on the compiler it self.

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.

I don't have the knowledge to configure webpack my self (which is one of the big reasons why I'm looking into next.js, and others). Can you give an example how I can achieve this?

[vhakulinen]

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.

Perhaps adding note to the docs that one can add "tsc": "tsc --watch --noEmit" to package.json and run tsc separately for typechecking? Then add link to this issue next to that and it would possibly avoid confusion on this topic.

Personally I would like to have the type checking build in into the provided dev build process, but I do understand the annoyance of the compilation time that typescript brings.

[samwightt]

It has now been four months since my last comment on this, and this experience still has not been improved (despite having a pull request submitted, which was denied). Multiple other comments (some with 70+ likes) have asked for the option to enable this (not supporting this by default, instead allowing users to willingly slow down their dev environment in return for better type checks). This has forced users to come up with unstable workarounds that don't have the same rich dev experience that official support would bring.

This is a big issue and I'm extremely disappointed that this still hasn't been resolved. The lackluster dev experience here has pushed me to avoid recommending Next, and by extension Vercel, to teams and other users in my network.

Please do something to fix this. This is a major blocker for me and a large amount of other users and is literally the only thing keeping me from using Next in my projects.

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

[samwightt]

It’s been 8 months since my last comment on here, a year since my first comment, and almost a year and a half since the issue was open. Just want to continue to reiterate how much of a bad dev experience this is, especially for newer developers. It’s also been a major reason why teams I’ve worked on haven’t ended up using Next.

We use Vite on my team, and it has this same behavior by default. One of the newer developers, who’s still learning TypeScript (as it’s a beast sometimes), will edit a type and not run a build before pushing. Sometimes those changes will cause a type issue in one of the files not open in VSCode, so they won’t get that error until it hits CI (just like I said in my last comment).

The problem here, and one I didn’t think about, was that they don’t know how to map the error they see to the file and line that it occurs on. Some of the files in our project are really large, and they don’t know how to navigate them as well as people who’ve been working on it for longer. They’ll often fix the change, forget to run a rebuild, and then encounter another problem in CI. So they’ll often ask another developer to help them out with fixing the problem.

Thankfully, Vite has a wonderful plugin for running TypeScript in development with incremental building. The dev experience is very nice and since introducing it, the number of errors in CI has gone down. Next, as far as I know, still doesn’t have an equivalent that integrates nicely with the dev server, which just makes the entire development experience worse.

With Vite or Snowpack or CRA, it either works out of the box or I can install a small package that integrates directly with the dev server. With Next, users are forced to either fuck around with their Webpack config, which goes against the entire reason they chose Next, or deal with awkward CLI workarounds using npm-run-all or something similar. Those integrate with the console, but they don’t integrate with the dev server. It’s easy for the TypeScript errors to be overwritten / just not seen if you have a lot of rebuild messages from Next.

I’ve had a lot of fun working in Next in side projects, but this has been a thorn in my side on every. single. one. It’s something that you think wouldn’t be an issue, but when you’ve worked in a framework like Snowpack, CRA, or Vite, the lack of a good dev experience around this becomes more and more annoying. On most of these projects, I often get so annoyed with having to debug issues in CI that I swap the app over to another framework. This is yet again why I no longer recommend Next to developers.

I understand the team has other priorities right now (the stuff with SWC looks super exciting!), but I just want to reiterate how bad of a dev experience this is currently. This upsets me not because it’s a feature that I want, but because it’s the only feature stopping me from using Next. It’s literally that annoying / bad for me. I really, really hope that something comes through the pipeline soon, cause I would love to have a development / deployment experience with Next where it doesn’t feel like I’m battling against CI.

[samingle]

Hey, just wanted to drop a note to say thank you for beating this drum. We're longtime typescript guys finding it absolutely preposterous that Next has chosen this implementation.

[markerikson]

Earlier in the thread, @timneutkens said ( #14997 (comment) ):

If you can figure out a performant way to do type checking we'd be happy to merge it

Given that the Next team is busy, it seems like the community would need to contribute this separately. Has anyone tried looking at what Vite does and applying a similar approach that could be filed as a PR?

[samwightt]

Has anyone tried looking at what Vite does and applying a similar approach that could be filed as a PR?

Clarification: Vite does this through a plugin (it has a built-in plugin system largely compatible with Rollup), not by default. Snowpack’s default TS template does this by default, though, so it might be worth exploring. CRA uses Webpack so that might be even better.

[effectivetom]

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"
  },
}

Nice solution. I would run both tasks with concurrently or such, otherwise when you exit with ctrl-c the "yarn dev" task remains in the background

I've been using this kind of setup without issue.

My config:

"scripts": {
    "dev": "concurrently -n NEXT,TS -c magenta,cyan \"next dev -p 1234\" \"yarn ts --watch\"",
    "ts": "tsc --noEmit --incremental --preserveWatchOutput --pretty"
}

Edit: as someone pointed out in a comment below, people might be hesitant to copy/paste code into their build config without understanding what it does. Here is a brief overview of what happens when you run yarn dev with the above config:

• concurrently runs two commands at the same time: next dev -p 1234 and yarn ts --watch
  • next dev is the standard NextJS build command
  • yarn ts is detailed below. The --watch flag automatically re-runs the build when you change a file
• The NEXT,TS -c magenta,cyan part of the script ensures that output from each process is labelled and coloured differently in your terminal so you can easily distinguish between them
• The ts command is the standard Typescript build command with a few flags
  • --noEmit means that type checking is performed but built files are not emitted (Next takes care of this already)
  • --incremental makes the TS build faster by storing information about previous builds
  • --preserveWatchOutput ensures that console output is not wiped with each new build
  • --pretty provides coloured formatting to make errors and other compiler output easier to read

[mikelehen]

I just ran into this. I was super confused when my code worked locally but failed to build in CI. Then I looked in VS Code and sure enough there were errors showing up there too. But the code was running fine locally and next dev wasn't complaining! I started wondering if somehow I was looking at the wrong file in VS Code or maybe VS Code wasn't saving my changes. I quit and restarted next dev to see if somehow it was failing to pick up my changes. I was getting really confused. Finally I tried introducing a really egregious error to the file and verified that that broke next dev so I finally realized that next dev was picking up my changes; it just wasn't type-checking my code! 😱

While technically I knew it was possible to have TypeScript transpile your code without actually compiling / type-checking it, it definitely didn't occur to me that that would be the default behavior in a mainstream dev tool. Even more surprising that it's not configurable, though I see people have found a myriad of workarounds. I hope you're making progress on this one!

[Mydayyy]

So given that the issue was converted to a discussion, can we assume that typechecking in development will never be introduced as an official option?

[mcmillion]

Granted I'm new to Next and newish to TS, but isn't being to detect these kinds of issues during development the entire point?

[samwightt]

Yeeeeep that's the general point 🙃 Supposedly they're working now on a rewrite of TSC in Go, so hopefully something will be coming soon, but in the meantime I genuinely have no clue why this still isn't an option.

[piccinnigius]

there isn't a solution yet? something to show errors in browser

[PVermeer]

I just started a new project to check out Next.js. Been programming with typed languages for years and always use TypeScript for web applications. I've never come across a framework that supports TypeScript and then is just plainly disables type checking in dev mode. This is the MAIN feature of TypeScript.

You are so opinionated and you can't even see why developers use TypeScript in the first place. Every time code compiles I want it to be type checked. This is to stop me and my fellow developers from making stupid mistakes while working out a problem and NOT finding out while we finally build the whole project. IDE's are not responsible for this. As you can see from previously comments and issues a lot of people are not prepared to sacrifice type checking for performance.

It should NOT be your decision to disable type checking in any build process. I think I move on and cannot recommend this project when the developer is very opinionated and does not get why and how people use TypeScript.

[effectivetom]

All these indignant comments are totally wild.

It is trivial to run the TS compiler alongside a Next build. There are several perfectly good workarounds detailed above which utilise this approach.

Why not spend your energy copying and pasting that config instead of complaining about the industry leading framework which you get for free?

[vhakulinen]

There are a few things at play here:

1. The modern web development environment's built systems are complicated if you're not familiar with them
2. Nextjs, being a industry leading framework, advertises that it has typescript support[1]
3. For some, between typescript and javascript, its typescript or nothing (especially for people who prefer statically typed languages)
4. Related to point 1, some people (myself included) are hesitant to copy paste things into their built systems without understanding the implications. As I pointed out earlier, if the docs mention that "hey, if you want compile time type checking, do this" it wouldn't necessarily be such a problem. But instead, its here, hidden in the issue tracker. Doesn't really give confidence for making such changes to the system built system.

1: Says this on the home page: "Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more. No config needed."

[effectivetom]

I appreciate your comment and definitely understand the viewpoint - this behaviour took me by surprise at first as well. I just wish people could articulate their feelings in a manner which is respectful and free of entitlement like you have, and do so after taking 5 minutes to follow some simple instructions to test out a workaround. Installing a single dev dependency and adding a couple of scripts to your package.json file is not challenging.

edit: After reading your comments on build tooling, I've updated my above comment with a more detailed description of how the suggested scripts work.

[shahkeyur]

Any update yet?

[nipunn1313]

Very easy workaround. I run tsc --watch in another terminal
(or in the same terminal via concurrently or npm-run-all).

[CombeeMike]

I also chose the path to run tsc --watch and next dev concurrently using this concrete setup:

  "scripts": {
    "db:studio": "dotenv drizzle-kit studio -- --port 5555 --config=./db/drizzle.config.ts",
    "dev": "concurrently -n DB_STUDIO,NEXT,TS -c cyan,grey,green \"npm run db:studio\" \"next dev\" \"npm run ts:watch\"",
    "ts": "tsc --noEmit --incremental --preserveWatchOutput --pretty",
    "ts:watch": "npm run ts -- --watch"
  },

This was working just fine, however since upgrading to app dir/router, I'm seeing the following TS errors in my console, whilst the app seems to be running just fine:

[TS] error TS6053: File '/path/to/repo/.next/types/app/api/trpc/[trpc]/route.ts' not found.
[TS]   The file is in the program because:
[TS]     Matched by include pattern '.next/types/**/*.ts' in '/path/to/repo/tsconfig.json'
[TS] 
[TS]   tsconfig.json:23:96
[TS]     23   "include": [".eslintrc.cjs", "next-env.d.ts", "**/*.ts", "**/*.tsx", "**/*.cjs", "**/*.mjs", ".next/types/**/*.ts"],
[TS]                                                                                                       ~~~~~~~~~~~~~~~~~~~~~
[TS]     File is matched by include pattern specified here.
[TS] 
[TS] error TS6053: File '/path/to/repo/.next/types/app/layout.ts' not found.
[TS]   The file is in the program because:
[TS]     Matched by include pattern '.next/types/**/*.ts' in '/path/to/repo/tsconfig.json'
[TS] 
[TS]   tsconfig.json:23:96
[TS]     23   "include": [".eslintrc.cjs", "next-env.d.ts", "**/*.ts", "**/*.tsx", "**/*.cjs", "**/*.mjs", ".next/types/**/*.ts"],
[TS]                                                                                                       ~~~~~~~~~~~~~~~~~~~~~
[TS]     File is matched by include pattern specified here.
[TS] 
[TS] error TS6053: File '/path/to/repo/.next/types/app/page.ts' not found.
[TS]   The file is in the program because:
[TS]     Matched by include pattern '.next/types/**/*.ts' in '/path/to/repo/tsconfig.json'
[TS] 
[TS]   tsconfig.json:23:96
[TS]     23   "include": [".eslintrc.cjs", "next-env.d.ts", "**/*.ts", "**/*.tsx", "**/*.cjs", "**/*.mjs", ".next/types/**/*.ts"],
[TS]                                                                                                       ~~~~~~~~~~~~~~~~~~~~~
[TS]     File is matched by include pattern specified here.

When removing ".next/types/**/*.ts" from tsconfig, the errors are gone and everything seems to working as expected, however, this is re-added automatically, everytime I start the dev server, so I'd expect that it really should be there 🤷‍♂️

FYI, I've bootstrapped my app using create T3 app which is where api/trpc/[trpc]/route.ts is "coming from".

I'd really appreciate some help on how to get rid of those errors since they make it hard to spot "real" errors during dev.

[CombeeMike]

I just fiddled around with this a bit further and found something which seems to be working for me:

• Create a tsconfig.watch.json with the following content:

  {
   "extends": "./tsconfig.json",
   "exclude": ["node_modules", ".next/types/**/*.ts"]
  }
  

• Use this in my ts:watch script: npm run ts -- --watch --project tsconfig.watch.json

This way I don't see any errors from files within .next/types in my TSC watch but would still see them in the IDE or on build, which both still use the original tsconfig.json which includes that folder.

I'm not 100% sure if there are situations where I could be missing important errors now in my watcher at dev time, but ATM this is looking fine for me.

[Tatamo]

It's probably a similar issue, I've encountered a type error related to the .next/types/ directory when running npm run dev. The npm script I've set is:

"scripts": {
  "dev": "npm run tsc && concurrently -r -k \"npm run tsc -- --watch\" \"next dev\"",
  "tsc": "tsc --noEmit --incremental --preserveWatchOutput --pretty"
}

I've inserted the initial npm run tsc to prevent launching the application and overlooking type errors that might occur during command execution. When I remove npm run tsc, the following error is reported only once and is immediately resolved, but this problem is frequently caused by git switch, and its impact on development is not negligible.

[15:02:14] Found 2 errors. Watching for file changes.

- event compiled client and server successfully in 86 ms (20 modules)
- wait compiling...
- event compiled client and server successfully in 86 ms (20 modules)
[15:02:15] File change detected. Starting incremental compilation...

[15:02:15] Found 0 errors. Watching for file changes.

This seems to occur when tsc runs before the .next/ directory gets updated by initial compilation in next dev. So I decided to handle this issue by inserting a sleep command:

"scripts": {
  "dev": "concurrently -r -k \"sleep 5 && npm run tsc && npm run tsc -- --watch\" \"next dev\"",
  "tsc": "tsc --noEmit --incremental --preserveWatchOutput --pretty"
}

This workaround is obviously not perfect. The 5-second sleep anticipates that the compilation by next dev will be completed within 5 seconds. Also, even if it is completed within 5 seconds, it implies that you must always wait 5 seconds until essential type errors are reported. Rather than relying on concurrently, it would be more desirable for next dev itself to do the type checking after updating the .next/ directory. I hope an opt-in option will be introduced.

[CombeeMike]

Just to be sure: You only see those errors on the initial npm run tsc, not on npm run tsc -- --watch?
I'm seeing those errors on my watch cmd and I have no idea how I could make it wait those x secs after files have changed 😕
Do you maybe know of any option to achieve this? I could definitely live with the downsides you mentioned for the time being.

[Tatamo]

Yes, my problem and the workaround are only for the initial error when executing the command.
I rarely encounter the same problem during --watch, and I'm sorry, but I do not have any ideas on how to set a wait time during watch command.

[CombeeMike]

Just FYI, I think I found a solution which seems to work for me and feels less hacky than a magic number sleep. See comment above.

[slutske22]

Wow this has been a pain point for years and continues to this day.

The strangest thing I'm experiencing now with Next14 is that types are not pulled from the node_modules folder, like 99.99999% of packages, but rather, types are generated dynamically in the .next/types folder. And this only happens either at build time, or during dev, when the user is on a specific page, the types for that page will be present in the .next/types dir structure.

This is insane. If I write some code for some pages and I want to pull in, say PageProps, they get auto-imported from .next/types/app/page.ts. But that file does not exist until I either build, or am in my browser navigated to a page. So if I want to statically check my types by running npx tsc in a process parallel with development, that will still fail because the ts def files are not present until you build or dev-nav there. What??

Is anyone else experiencing this issuein 2024 with Next 14? I just started a new next project last week with 14 and am seeing this right away. Am I doing something stupid and obviously wrong? I also don't see anything about this anywhere in the documentation.

[notbnull]

This is correct. Looks like there's no 'easy' work around either since they won't simply give us a --typecheck style flag on build. or a next typecheck

[rob2d]

The comment from CombeeMike still seems relevant 2 years later.

For VSCode I've found it convenient to just have a task defined @ .vscode/tasks.json as when my IDE is open it is usually when I'd possibly be doing refactors etc (with or without a dev server running)

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "TSC (Watch Mode)",
      "type": "shell",
      "command": "npm run ts:w",
      "windows": {
        "command": "npm run ts:w"
      },
      "group": "none",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]
}

Seems this should be opt-in for a development build server at the very least though when looking at DX in every other Typescript compatible environment.

[markabrahams]

I used Next.js for the first time on my latest project, and was puzzled with the behaviour that led me to this Github issue. The developer experience due to this issue is terrible. My short experience in implementing parallel TypeScript watching as a workaround is that it didn't match one-to-one the errors reported by the Next.js build mechanism, and as such wasn't useful. I'm actively migrating off Next.js, with this issue the singular reason for migrating. That Next.js / Vercel has not fixed this 4 years after being reported shows a contempt towards their developer community and indeed towards software development in general.