Why does the @nx/eslint/plugin register new projects wherever it finds package.json?

[mattfysh]

relevant code:

nx/packages/eslint/src/plugins/plugin.ts

Lines 53 to 62 in 1a85787

	const projectFiles = globWithWorkspaceContext(
	context.workspaceRoot,
	[
	'project.json',
	'package.json',
	'**/project.json',
	'**/package.json',
	].map((f) => join(configDir, f)),
	nestedEslintRootPatterns.length ? nestedEslintRootPatterns : undefined
	);

this is causing all sorts of chaos. previously a project was defined by the presence of a project.json - NOT package.json

[edbzn]

Hi, multiple plugins are working this way, they try to find what looks like a project, and a project can be defined by both project.json and package.json. However, I think this could be improved by aligning all the plugins, see #22037.

[mattfysh]

should all plugins have authority over defining the core structure of projects? i feel like that could get messy very quickly given how integral project locations are to the project graph, and to how nx functions in general

as it happens i had a few package.json files in various locations for a number of reasons, e.g

1. some only had { type: module }, mostly used in places where i had a pulumi program nested inside a monorepo project. these are required for me to run my pulumi programs with a custom typescript runtime, but they are already nested inside an existing project and I do not wish them to indicate a new discrete project

2. in a couple of other places (again, nested within existing projects) i am defining some containers including the package.json file which is to be copied into the container, and has nothing to do with the nx monorepo

this is not a great inference path, why are project locations not determined solely by the presence of project.json?

[mattfysh]

@edbzn did you have any thoughts on rolling back the @nx/eslint/plugin approach of defining where projects are located? one thing I forgot to mention is that I had to add a name property to all the package.json files the plugin found otherwise I would get an error saying the project's name was not defined / or more than one project with same name. Seems a bit strange to be updating code to appease a plugin inside folders you don't want that plugin to be operating in.

[jaysoo]

The @nx/eslint/plugin will match any package.json/project.json files as long as they are not ignored by your ESLint configuration. This is to keep consistency with how ESLint would work in an IDE, i.e. non-ignored files belong to a project and will be linted.

For older versions, you want to check the ignorePatterns option in your config. For newer versions (i.e. ESLint 9+ with new config), you want to check the ignores option.

What sorts of problems are you running into @mattfysh ?

[mattfysh]

hi @jaysoo thanks for the reply, I detailed some of the problems above. I think you may have misunderstood what I mean by "register new projects wherever it finds package.json". I'm not talking about the linter being run on the package.json file, I'm talking about how the plugin creates a new nx project node inside createNodes for every package.json file found

For example, lets say my layout has these two files:

1. services/mysvc/package.json + project.json
2. services/mysvc/container/files/package.json

For some reason, the eslint plugin is adding TWO project nodes (visible in nx graph), and a big problem with that is package.json was never meant to indicate an nx project node. ONLY project.json should be doing that.

So I am getting errors related to file 2, for example that package.json may not have a name property -- but because that folder is not intended to be an nx project, nx should not be running any validation logic across this erroneously detected location

[shinebayar-g]

I'm running into the exact same problems as you described @mattfysh. I have various package.json to override certain dependencies for a/b testing. However, nx is registering any folder that contains package.json as nx project. Is there any way to disable this behavior? I thought only project.jsons are considered as a project.

[mattfysh]

hey @shinebayar-g - I ended up migrating to biome, so once I got rid of the eslint plugin the project structure returned to the expected layout

[shinebayar-g]

I removed all eslint related packages and config. But it's still showing up as a nx project.
nx show project subfolder1 shows that there is 1 target called nx-release-publish

Created by nx/core/package-json from apps/foo/src/subfolder1/package.json.

I assume it could go away if I set "private": true, in my package.json, now it says No targets configured. but still considering it as a project.

My setup looks like this:

package.json # installs pkg-v1
apps/foo
├── project.json
└── src
    ├── bar.ts # imports pkg-v1 from root level package.json
    └── subfolder1
        ├── baz.ts # imports pkg-v2 from the relative package.json
        └── package.json 

So I could test pkg-v2 in this specific folder without installing the package with different alias name and rewriting all my import statements..

nx version: v20.6.4

[tphbrok]

@shinebayar-g I ran into a similar issue where a repository only had one package.json (in the root), and project.json everywhere else. That package.json was picked up as another project, which it wasn't.

I tried adding package.json to the ESLint config ignores option, but that didn't help.

What worked in the end was adding package.json to the excludes in the ESLint plugin configuration in nx.json (so not in the ESLint config).

"plugins": [
  {
    "plugin": "@nx/eslint/plugin",
    "exclude": ["package.json"]
  }
]

Likely adding **/package.json will prevent additional projects being detected by Nx, although I was not able to try it because I only had one package.json.