Inconsistent inclusion of peerDependencies

[yen-tt]

Hello! I'm in the process of migrating from v2 to v3 for the package. But I'm seeing dependencies listed under both devDependencies and peerDependencies doesn't get included in the generated third party license file for V3. Here's an example of a package.json where react is a PeerDep but it's also in devDep for testing and other development usage within the app (e.g. packages like react-redux have this structure):

{
  "name": "test",
  "version": "0.1.0",
  "description": "Test",
  "scripts": {
    "test": "generate-license-file --input package.json --output THIRD-PARTY-NOTICES --overwrite"
  },
  "devDependencies": {
    "generate-license-file": "^3.0.0",
    "react": "^18.2.0"
  },
  "peerDependencies": {
    "lodash.isequal": "^4.5.0",
    "react": "^18.2.0"
  }
}

lodash.isEqual would be listed but not react. I'm not sure if that's intentional but I would expect any dependencies listed under peerDependencies should be included regardless if it's also in devDep.

Thank you for your time

[tobysmith568]

Hey @yen-tt ,

Thanks for raising this, there's certainly a bug here but we don't think it's quite the same as perhaps what you're reporting - though we do recognise that it can come down to what you intend to use our generated output for.

From our perspective, the bug here is that peer dependencies should not appear in the output at all, no matter if they're also a devDependency or not.

Our rationale for this is: in general, this package exists because the licenses of dependencies often contain phrases like:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

We don't include dev-dependencies in our generated output because they're not included in build outputs. In other words, if a package isn't included in your build, then there's no "copy or substantial portion" of that package that the license needs distributing alongside.

Under typical usage, the same is true for peer dependencies. Packages should be listed as peer dependencies when your package depends on said package in order to function, but the package is installed seperately. A common example is plugins. (1) For example, one should list "eslint" as a peer dependency in the package.json of an ESLint plugin. However, because that ESLint plugin doesn't distribute the ESLint code itself, it doesn't need to distribute the ESLint license either.

Over the next day or two we'll roll out a fix in a patch release to remove peer dependencies from the generate output by deafult. That being said, we'd be interested to hear more about your usage of peer dependencies and your intended usage of our package's output to determine if there are any additional factors that we've not considered and if there's scope for making this more configurable.

Thanks!

[tobysmith568]

Hey @yen-tt

Our fix for peer dependencies appearing in outputs was released yesterday in version 3.0.1.

I'm going to close this issue now that peer dependencies are no longer inconsistent, but please do reach out to us here if you have any further concerns about this behaviour of if there's still any reason why you feel you can't update to V3.

Thanks!