[NEXT-671] Next.js 13.2.1 - Module '"next/navigation"' has no exported member 'usePathname'.

[TadejPolajnar]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release1

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.3.0: Thu Jan  5 20:48:54 PST 2023; root:xnu-8792.81.2~2/RELEASE_ARM64_T6000
Binaries:
  Node: 16.15.1
  npm: 8.11.0
  Yarn: 1.22.19
  pnpm: 7.18.2
Relevant packages:
  next: 13.2.1
  eslint-config-next: 13.2.1
  react: 18.2.0
  react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue

https://stackblitz.com/edit/nextjs-q4nrme?file=package.json,tsconfig.json,pages%2Findex.tsx

To Reproduce

import { usePathname } from 'next/navigation';

export default function Home() {
  const pathname = usePathname();

  return <div>Pathname: {pathname}</div>;
}

Describe the Bug

Hook usePathname works as expected, it returns current path name however typescript throws an error which doesn't allow you to build the page.
Typescript error: Module '"next/navigation"' has no exported member 'usePathname'.

As a temporary solution I used // @ts-ignore to suppress the error for now.

Expected Behavior

Typescript type of usePathname needs be exported correctly and typescript error should disappear.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_{From SyncLinear.com | NEXT-671}

[lionelrudaz]

Same issue with useSearchParam.

Here's my code:

"use client";

import Link from 'next/link';
import { useSearchParams } from 'next/navigation';
import { CaretLeft } from 'phosphor-react';

type Props = {
  defaultUrl?: string
  style?: "flat" | "shadow"
}

const BackButton = ({
  defaultUrl,
  style
}: Props) => {
  const searchParams = useSearchParams();
  const returnUrl = searchParams.get('returnUrl') ?? defaultUrl;
  
  return (
    <Link
      href={`${returnUrl ? returnUrl : "/"}`}
      className={`mr-auto rounded-full p-2 flex items-center justify-center ${style === "shadow" ?  "bg-white shadow-md" : "bg-gray-200"}`}
      passHref
    >
      <CaretLeft size={24} color="black" weight="regular" />
    </Link>
  )
};

export default BackButton;

Was working with NextJS 13.1, not working anymore after the update to Next 13.2.

@TadejPolajnar how did you solve the error exactly? It doesn't work to add a // @ts-ignore in the beginning of the file.

I hope this helps.

[TadejPolajnar]

@lionelrudaz you need to insert it right before the problematic row, here is an example:

import Image from 'next/image'
import { useMemo } from "react";
// @ts-ignore
import { usePathname } from 'next/navigation';

[lionelrudaz]

@TadejPolajnar it works as a temporary fix :)

[ooyay]

make sure navigation types is exist in next-env.d.ts

/// <reference types="next" />
/// <reference types="next/image-types/global" />
/// <reference types="next/navigation-types/navigation" />

// NOTE: This file should not be edited
// see https://nextjs.org/docs/basic-features/typescript for more information.

[TadejPolajnar]

@ooyay next-env.d.ts changes every time you build the app or run development.

[TadejPolajnar]

Based on a review I received on proposed PR, this is expected behavior. usePathname can only be used inside new app directory.

[ooyay]

@ooyay next-env.d.ts changes every time you build the app or run development.

I don't know, but the error was coming up until this line comes

[kevin-courbet]

I'm still getting this error in my App directory project... don't think this is fixed. 13.2.1

[AlanMorel]

I can also confirm that I'm also getting this issue when upgrading to 13.2.

My project is an app directory project as well. I don't think this issue should be closed.

[sabbircste]

Module parse failed: Unexpected token (6:5) You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.

[kieranm]

Also seeing this issue in the app directory in 13.2. @TadejPolajnar I would suggest reopening.

[balazsorban44]

So it looks like the OP's issue is that they are trying to use next/navigation, while appDir: true is not enabled in the next.config.js file, as well as there is no app directory present. These conditions are the current requirement for us to correctly update the next-env.d.ts file for those types to be included.

[kieranm]

We are using the app folder and have appDir: true and ran into this issue. I think (I could be wrong) we needed to run next dev in order to have the types be updated. next dev isn't run in CI environments which is which is why our builds started failing after Dependabot tried to bump the version. Does this sound right?

[kieranm]

It seems like next build also adds the correct types so I can't really explain this. In any case it seems to have added the correct types now.

[Willem-Jaap]

Also having this issue, indeed the issue seems to be that the next-env.d.ts is not updated in the linting proces.

42:11  Error: Unsafe assignment of an `any` value.  @typescript-eslint/no-unsafe-assignment
42:22  Error: Unsafe call of an `any` typed value.  @typescript-eslint/no-unsafe-call

[wyattjoh]

In order to get the update to the types, you have to run next dev to generate updated next-env.d.ds file. Due to how TS type augmentation works, this was a neccesary evil. Once you run that, it should update it to include one of the following:

/// <reference types="next/navigation-types/navigation" />
/// <reference types="next/navigation-types/compat/navigation" />

This was changed in #45919 to ensure that users who are using both /pages and /app will have types representative of the hybrid use case.

[Willem-Jaap]

I know this is the fix for development and actually works, but next dev is (and should obviously not be) used in a pipeline or github actions.
I have a pipeline which lints all code using 'next lint'. This validates all used types. If these types are not set correctly, It can't validate them, therefore the pipeline failes.

A possible solution is to also generate the file in a postinstall step, which would solve the problem.

[wyattjoh]

Close this prematurely! Going to keep it open to see if we can smooth this or not.

[giovanedann]

Hey! im on 13.2.1 and even after running next dev my declaration file does not set these type declarations lines by default

I have already tried to remove node_modules and re-install packages, but the issue persists. Am i doing something wrong? Cuz i saw some comments that running the development server fixed the issue by adding those reference lines

Im not using the app directory, im using the pages directory, maybe is something related?

edit: i started a new project, and the declaration file is created with the correct references, seems like the problem is with the pages directory?

after running next dev this is the file generated:

/// <reference types="next/image-types/global" />

// NOTE: This file should not be edited
// see https://nextjs.org/docs/basic-features/typescript for more information.```

[balazsorban44]

@kieranm

We are using the app folder and have appDir: true and ran into this issue. I think (I could be wrong) we needed to run next dev in order to have the types be updated. next dev isn't run in CI environments which is which is why our builds started failing after Dependabot tried to bump the version. Does this sound right?

It seems like next build also adds the correct types so I can't really explain this. In any case it seems to have added the correct types now.

Since both next dev and next build update types, this should not be an issue in CI or locally. 🤔

@Willem-Jaap

I know this is the fix for development and actually works, but next dev is (and should obviously not be) used in a pipeline or github actions.
I have a pipeline which lints all code using 'next lint'. This validates all used types. If these types are not set correctly, It can't validate them, therefore the pipeline failes.

Fixing this during linting is already tracked here #46104. (There is also a PR #46249)

@giovanedann

Im not using the app directory, im using the pages directory, maybe is something related?

Exactly. This type is generated only when appDir: true is set and you have an app directory. See my comment #46360 (comment)

[giovanedann]

Oh! i missed this comment, my bad!

So, the solution for that is to refactor the project to use the app directory or lock next in 13.1.6?

[wyattjoh]

If you're not using app directory @giovanedann, then you should continue to use next/router, next/navigation is for use with projects utilizing app directory.

[giovanedann]

@wyattjoh sure, appreciate your time! Thank you very much! @balazsorban44

[jdouglass]

This might be a long shot here, but I get this exact same error message when I tried using turborepo in their monorepo configuration. I had ui components in a separate package folder, however, those ui components needed useSearchParams and usePathname. Is my only option as of right now is to use // @ts-ignore as a temporary fix or is there a better solution for my case?

[tgroutars]

Just want to add: This doesn't occur for me with next lint (afaik that command doesn't run type checks, just eslint?). But it does happen when I run type checks (tsc --noEmit) on github actions.

#46249 generates next-env.d.ts on next lint so it won't fix the issue unless next lint runs before typechecks.

Best way would be to have an explicit way to generate next-env.d.ts, either in postinstall or before running typechecks

[timinho111]

Also running into this issue when upgrading from next 13.1.6 to 13.2.1 without changing anything else.

/// <reference types="next/navigation-types/navigation" />

is set correctly after running next dev but it does not find useSearchParams() and usePathname().

Should next/navigation always been used when using the app directory or should next/router be used when using the router outside of the app directory?

[ijjk]

Hi, this has been updated in the latest canary of Next.js, please update and give it a try!

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.