no-extraneous-dependencies doesn't support nested package.json

[nkt]

Example of my project structure:

├── package.json
├── src
│   ├── components
│   │   ├── Avatar
│   │   │   ├── Avatar.css
│   │   │   ├── Avatar.js
│   │   │   ├── README.md
│   │   │   └── package.json
│   │   ├── Button
│   │   │   ├── Button.css
│   │   │   ├── Button.js
│   │   │   ├── ButtonSpinner.css
│   │   │   ├── ButtonSpinner.js
│   │   │   ├── README.md
│   │   │   └── package.json

Root package.json contains all dependencies, nested package.json looks like this:

{
  "name": "Avatar",
  "main": "Avatar.js"
}

That's why I got wrong warnings:

src/components/Avatar/Avatar.js
  1:1  error  'react' should be listed in the project's dependencies. Run 'npm i -S react' to add it            import/no-extraneous-dependencies
  2:1  error  'classnames' should be listed in the project's dependencies. Run 'npm i -S classnames' to add it  import/no-extraneous-dependencies

Is this fixable?

[jfmengels]

@sindresorhus Any chance you have already written a tool to list all package.json files (like pkg-up but multiple? I might create one otherwise.

@nkt Out of curiosity, what is the use of those package.json files? Do you distribute plenty of packages like this?

[jfmengels]

@benmosher I propose to have an option (name TBD) to use all package.json files, and keep the current behavior by default. I'm not used to monorepos, but I guess that looking at all previous package.json files is not always wanted, depending on how you declare your dependencies for each sub-package.

[nkt]

@jfmengels no, I'm not. I use package.json instead of index.js.

I'm not used to monorepos

I'm too. It's not monorepo. It's react component library.

react-starter-kit uses the same approach.

[sindresorhus]

I haven't. Go ahead.

[benmosher]

@jfmengels I'm thinking maybe this just shouldn't be supported. Autofix would be impossible in this case, plus npm i src/components/Avatar would fail if it did not declare all of its dependencies.

I occasionally run into problems with the resolvers because they are descendants of the folder with the root package.json for this project. CI passes, but installing from npm fails.

Up to you, though, if it's easy and sane to do it behind an option.

[jfmengels]

I'm thinking maybe this just shouldn't be supported

I'm having my doubts too, but I'm not sure what the viable option would be for people who want to have such as project setup, except turn this rule off either entirely or in that folder. Well, either that or stop using package.json instead of index.js just because of this rule.

I do think it's strange to use a package.json file for something that is not a package. But the use case might come for monorepos (though it's probably better to wait for issues from monorepo maintainers to do anything prematurely to handle those.

though, if it's easy and sane

Easy: Meh, have to create a new package and have to add a new dependency here.
Sane: No clue here 😅

Any comments from others to help us decide? Especially about the following concern:

I occasionally run into problems with the resolvers because they are descendants of the folder with the root package.json for this project. CI passes, but installing from npm fails.

[nkt]

You should know, package.json allows define custom entry points for browser and server environments:

{
  "name": "GoogleMap",
  "main": "./ServerGoogleMap.js",
  "browser": "./GoogleMap.js"
}

What if rule will check path.join(process.cwd(), 'package.json') and if it exists, use them.
For monorepos you can add monorepo option.

[jfmengels]

You should know, package.json allows define custom entry points for browser and server environments

Didn't know that, thanks!

What if rule will check path.join(process.cwd(), 'package.json')

You would then necessarily need to use ESLint from the root of the project, which is not always the case. I'm not sure your editor does that for instance when you open your workspace folder.

[nkt]

@jfmengels maybe eslint has API which gives root config filename? I mean if config /project/.eslintrc, you can call path.dirname(rootConfigFile) and it will be cwd from previous example.

[jfmengels]

I couldn't find one, but that wouldn't work either for some projects.
1 - You don't necessarily have a .eslintrc next to your package.json

├── package.json
├── client
│   ├── .eslintrc
│   └── file1.js
└── server
    ├── .eslintrc
    └── file2.js

2 - .eslintrc files are cascading, so you can have multiple ones. (I know you said root config, just wanted to clarify for other), but this could have worked if ESLint gave the list of all files and we could have taken the "first" one.

This still wouldn't address the concern @benmosher mentionned about the sub-packages not declaring all their dependencies, or is that what you meant with the monorepo option?

[acusti]

This would be great for me. I work on a monorepo (here’s why) with a root package.json and sub-directories with their own package.json. As it stands, I just have to disable this rule, which is a bummer, because it’s so useful.

As I understand it, in order to resolve the installed dependencies accurately (in a way that matches node’s module system), the getDependencies function would basically need to recurse up all found package.json files, updating the context arg as it goes, until the app root directory, then merge the dependencies object from each package.json (something like Object.assign({}, ..._.pick(packageContents, 'dependencies')), where packageContents is an array of the contents from root to leaf).

I understand the concerns about introducing this, but I would still like to put a strong favorable vote towards adding this as an option. Monorepos are fairly common and probably worth supporting. See Lerna for evidence of this, which can also serve as a way to make a quick example repo test case.

And in terms of the more general question of sub-packages not declaring all their dependencies and therefore having to do multiple npm installs in your codebase, I think that’s just part of the tradeoff one makes. Part of the benefit of Lerna is having a CLI that makes it easy to do monorepo npm stuff.