VSCode ESLint extension hoisting workaround

[00:00 - 00:08] We previously did the following setup for pnpm. We set our public-hoist-pattern to an empty array.

[00:09 - 00:28] If you remember, by default pnpm has a public-hoist-pattern of all Prettier plugins and all ESLint plugins. In practice, we saw that removing this public-hoist-pattern works fine in the command line. However, it turns out that it doesn't work fine in VSCode's ESLint plugin.

[00:29 - 00:45] Let me show you. Here I have opened our frontend-nextjs page.tsx file. If we look at the output window for Prettier, we can see that it runs fine.

[00:46 - 01:08] The Prettier extension has no problem running with the setup that we have, and it correctly loads our config. The reason for that is that our root package.json contains Prettier and the plugin that we're using. So the prettier VSCode extension will correctly read that from the monorepo root and then apply it.

[01:09 - 01:24] However, in frontend-nextjs, if I go to our ESLint configuration, we can see that it fails to correctly calculate the config file. It fails with "Failed to load plugin react-hooks".

[01:25 - 01:50] The reason for that is that our frontend-nextjs ESLint config file is the one that defines this react-hooks plugin by extending the next/core-web-vitals plugin. The ESLint extension for VS code is then going to search for this plugin in the root of the monorepo. It is not going to find it.

[01:51 - 02:05] The actual underlying react-hooks plugin is going to be in the node_modules folder, of frontend-nextjs rather than in the root node_modules folder. And because of that the ESLint VSCode extension cannot load it.

[02:06 - 02:22] To fix this, we're going to change our .npmrc config. Currently we have the empty public-hoist-pattern and I'm going to change that to allow hoisting of everything eslint.

[02:23 - 02:32] So this means everything that begins with or ends with or has eslint in the middle. So this means any package that has ESLint somewhere in its name.

[02:33 - 02:52] If we need it to set this for a second package, we could do it by copying this line and doing, for example, Prettier. So after I change this config, I'm going to run pnpm install and it's going to ask me to recreate the root node_modules folder.

[02:53 - 03:11] This is necessary because now different packages are going to move to be moved from workspace node_modules into the root node_modules of the Monorepo. After we've done this, I can go back to VSCode and I can restart the ESLint server. It's going to take a moment.

[03:12 - 03:19] I'm waiting for the output to show up here. There it is. Now this is the restart and we no longer have an error.

[03:20 - 03:36] And we can verify that ESLint is running by defining a variable "a" of type "any" equals, let's say "no". If I hover over this, I'm going to see an ESLint error. So we know that now ESLint is running correctly.

[03:37 - 03:47] It is unfortunate that we need to do this workaround, but this is the reality of day to day software development. Sometimes we just need to work around problems in our tooling.

[03:48 - 03:59] As we saw before, everything worked correctly from the command line. But VSCode extensions are a different matter, and there are other similar problems that you could run into.

[04:00 - 04:15] If that happens, the public-hoist-pattern option is one avenue of fixing some of those problems. Let me quickly commit this. I'm going to commit this as "Workaround for VSCode ESLint extension breaking when ESLint plugins are not hoisted to the root".

[04:17 - 04:30] And the actual commit is a single line change. That's all for this lesson, and I'll see you in the next one.