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