next.js: Parsing error: Cannot find module 'next/babel' in Visual Studio Code

I was able to get this working also by installing next in the root of my pnpm workspace. I was curious to see if there was a better way and I managed to come up with a workaround I haven’t seen yet, maybe it would be useful to someone else.

I’m not sure where the above mentioned line comes into play, but I found the problematic part of the config for me was this line:

https://github.com/vercel/next.js/blob/cae96f27ec53cd42e992a748b9727852df9247c5/packages/eslint-config-next/index.js#L85

Which makes total sense because I only experience this issue in certain js config files, not in typescript because that uses the typescript parser rather than the babel one.

In order to workaround this, I installed next in the eslint config package within my workspace and I used require.resolve to supply the babel parser with an absolute path to next/babel within my sharable config. It looks like this:

/**
 * @type {import('eslint').Linter.Config}
 */
module.exports = {
  extends: ['next/core-web-vitals', 'turbo', 'prettier'],
  ignorePatterns: ['node_modules', 'dist'],
  parserOptions: {
    babelOptions: {
      presets: [require.resolve('next/babel')],
    },
  },
};

So far, I haven’t found any unintended side-effects. I still have some testing to do in order to be certain.

I think I understand. The discussions here have all been focused around monorepo or multi-package repo setup. Are you currently using a package manager to leverage this functionality? All the major players have support now, but I use pnpm. When I refer to root, I am saying at the very base directory of my project, there is a file called pnpm-workspace.yaml and this tells me where I have subpackages or projects installed. In yarn or npm this will be workspaces property in package.json. If you are not using these features, you might check it out to see if it would be good for your way of doing things.

The reason why it works correctly when you open a project in VSCode directly is because often times extensions use default install locations and since you have an unusual layout, VSCode just gets confused. The ESLint setting “eslint.workingDirectories” is an important setting for this type of scenario. One of my next projects is setup like this:

// .vscode/settings.json

{
  "eslint.workingDirectories": [
    { "pattern": "apps/*/" },
    { "pattern": "packages/*/" }
  ]
}

This allows each project in apps/ or packages/ to supply their own linting config and the extension should read from the config of the project you’re in. Hopefully that helps!

If you install the project with pnpm this error will appear. I tried adding public-hoist-pattern[]=next* to the .npmrc in the root project, reinstall and this error no longer appears.

Hi all ☀️, I just found a very simple fix for that bug in this Stack Overflow answer 👉 https://stackoverflow.com/a/70421220/7103634

In eslint.json, we just need to replace "extends": "next/core-web-vitals" by "extends": ["next/babel","next/core-web-vitals"]

@JanKaifer I can make a PR if you think the fix is right. Let me know 🙏

A somehow cleaner fix for this is to not let ESLint use the next/core-web-vitals extension for linting non-jsx / tsx files in the first place:

{
  // You might want to additionally set this in monorepos where Next.js app is in a subdir
  "root": true,
  "extends": ["next/core-web-vitals"],
  "overrides": [
    {
      // Adapt to your needs (e.g. some might want to only override "next.config.js")
      "files": ["*.js"],
      // This is the default parser of ESLint
      "parser": "espree",
      "parserOptions": {
        "ecmaVersion": 2020
      }
    }
  ]
}

Hi all ☀️, I just found a very simple fix for that bug in this Stack Overflow answer 👉 https://stackoverflow.com/a/70421220/7103634

In eslint.json, we just need to replace "extends": "next/core-web-vitals" by "extends": ["next/babel","next/core-web-vitals"]

@JanKaifer I can make a PR if you think the fix is right. Let me know 🙏

This workaround isn’t effective in all cases - just look at the full thread on Stack Overflow. That’s why I came up with https://github.com/vercel/next.js/issues/40687#issuecomment-1378845989 which is a bit more sensible workaround in my opinion.

Ultimately, I think we should tackle the problem at source (I feel like https://github.com/vercel/next.js/issues/40687#issuecomment-1251451833 & https://github.com/vercel/next.js/issues/40687#issuecomment-1251778801 are going into the right direction) instead of applying some pseudo workarounds.

Hi all ☀️, I just found a very simple fix for that bug in this Stack Overflow answer 👉 https://stackoverflow.com/a/70421220/7103634

In eslint.json, we just need to replace "extends": "next/core-web-vitals" by "extends": ["next/babel","next/core-web-vitals"]

@JanKaifer I can make a PR if you think the fix is right. Let me know 🙏

Just wanted to point out that this requires a VS Code restart to take effect. Worked great for me.

A somehow cleaner fix for this is to not let ESLint use the next/core-web-vitals extension for linting non-jsx / tsx files in the first place:

{
  // You might want to additionally set this in monorepos where Next.js app is in a subdir
  "root": true,
  "extends": ["next/core-web-vitals"],
  "overrides": [
    {
      // Adapt to your needs (e.g. some might want to only override "next.config.js")
      "files": ["*.js"],
      // This is the default parser of ESLint
      "parser": "espree",
      "parserOptions": {
        "ecmaVersion": 2020
      }
    }
  ]
}

IMO, this is the cleanest solution with no hacks:

• no global .vscode settings for workspaces (yet another source of truth for workspaces)
• no next/babel addition that causes build issues (swc incompatible)
• no require.resolve for those using .json eslint files instead of .js

@balazsorban44 next was removed from eslint-config-next’s peer dependencies in https://github.com/vercel/next.js/pull/38009 because npm simply won’t resolve next@canary in this case. And we can do nothing about this…

More details: https://github.com/npm/cli/issues/4958

Thanks for pointing out the issues with the SO solution

I tried the second solution in that SO thread: add "eslint.packageManager": "pnpm" into vscode config It seems to work fine: https://github.com/JanKaifer/next-repro-40687/blob/ea5ec944e827ff3e2498b7dc5407ffa61eff8732/.vscode/settings.json#L2

Is there any “solution” or “workaround” for this? I am unsure as to what can be done at this point.

My not-so-optimal workaround for this has been installing Next on the root workspace, i.e., pnpm install -Dw next@<x.y.z>. Makes the whole error go away. It’s been beneficial too in working with packages where I need types from Next.

@DavNej, Thanks for the suggestion. Further issue not observed.