next.js: Parsing error: Cannot find module 'next/babel' in Visual Studio Code
What version of Turborepo are you using?
1.4.7
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Describe the Bug
Hi! I just created a turborepo project using npx
, and VSCode throws the following error:
Parsing error: Cannot find module 'next/babel'
Require stack:
- /Users/celia/.dev/flex/node_modules/.pnpm/next@12.3.0_ir3quccc6i62x6qn6jjhyjjiey/node_modules/next/dist/compiled/babel/bundle.js
- /Users/celia/.dev/flex/node_modules/.pnpm/next@12.3.0_ir3quccc6i62x6qn6jjhyjjiey/node_modules/next/dist/compiled/babel/eslint-parser.js
- /Users/celia/.dev/flex/node_modules/.pnpm/eslint-config-next@12.3.0_dyxdave6dwjbccc5dgiifcmuza/node_modules/eslint-config-next/parser.js
- /Users/celia/.dev/flex/node_modules/.pnpm/@eslint+eslintrc@0.4.3/node_modules/@eslint/eslintrc/lib/config-array-factory.js
- /Users/celia/.dev/flex/node_modules/.pnpm/@eslint+eslintrc@0.4.3/node_modules/@eslint/eslintrc/lib/index.js
- /Users/celia/.dev/flex/node_modules/.pnpm/eslint@7.32.0/node_modules/eslint/lib/cli-engine/cli-engine.js
- /Users/celia/.dev/flex/node_modules/.pnpm/eslint@7.32.0/node_modules/eslint/lib/cli-engine/index.js
- /Users/celia/.dev/flex/node_modules/.pnpm/eslint@7.32.0/node_modules/eslint/lib/api.js
- /Users/celia/.vscode-insiders/extensions/dbaeumer.vscode-eslint-2.2.6/server/out/eslintServer.jseslint
This is from a project out-of-the-box, created with npx create-turbo
. I haven’t made any changes to the bootstrapped files.
I have tried a few solutions:
- This workaround suggested by Saral Karki: basically adding
"next/babel"
in the list of extends, inside ofeslint-config-custom
. It does “fix” the error inside VSCode, making it stop yelling at me. - However, with this change,
pnpm run lint
breaks throwing the following error:Failed to load config "next/babel" to extend from.
. I then found this thread, where Domi said the first fix I tried is basically a “hack”. I then tried tinkering around with Akasha’s answer, with no success. - Setting up
eslint.workingDirectories
to mypackages/
andapps/
folders in my.vscode/settings.json
(making sure I had no conflict in my personalsettings.json
, no success here either. - Setting up
eslint.packageManager
topnpm
, nothing here. - Installing
@babel/eslint-parser
, nothing either.
Note: the issue does not appear when using npm
or yarn
as the default package manager, configured in the create-turbo
CLI.
Expected Behavior
VSCode doesn’t throw an error about a parsing error, and the build runs correctly.
To Reproduce
- Run
pnpx create-turbo
ornpx create-turbo
- Setup using CLI as normal, and select
pnpm
as the package manager. - Open Visual Studio Code with the ESLint extension code installed.
- Open any
.eslintrc.js
or anynext.config.js
file in the default project. - The error will be visible at the top of the IDE window.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 20
- Comments: 30 (9 by maintainers)
Commits related to this issue
- fix: eslint error. https://github.com/vercel/next.js/issues/40687 — committed to editablejs/editable by big-camel 2 years ago
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 usedrequire.resolve
to supply the babel parser with an absolute path tonext/babel
within my sharable config. It looks like this: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 calledpnpm-workspace.yaml
and this tells me where I have subpackages or projects installed. In yarn or npm this will beworkspaces
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:
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 addingpublic-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: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.
Just wanted to point out that this requires a VS Code restart to take effect. Worked great for me.
IMO, this is the cleanest solution with no hacks:
.vscode
settings for workspaces (yet another source of truth for workspaces)next/babel
addition that causes build issues (swc incompatible)require.resolve
for those using.json
eslint files instead of.js
@balazsorban44
next
was removed fromeslint-config-next
’s peer dependencies in https://github.com/vercel/next.js/pull/38009 becausenpm
simply won’t resolvenext@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#L2My 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.