Add support for monorepos with root-level dependencies

[jcfranco]

How are you using generate-license-file?

CLI+Library

Is your feature request related to a problem? Please describe.

Generating individual license files for individual packages in a monorepo isn't reliable unless each package has a local node_modules and package-lock.json. This requirement doesn't work with monorepo setups where dependencies are installed at the top level, separate from the license-target package.

Referencing the root package.json results in incorrect license information for the target package (example), while referencing the target package’s package.json returns no licensing information (example).

Describe the solution you'd like

Allow specifying a root package.json or an alternative lookup location for license retrieval when the target package doesn’t have its dependencies installed locally.

Additional context

We worked around this by installing each package’s dependencies locally before running generate-license-file (see Esri/calcite-design-system#11640 for additional details).

Also, just wanted to say thanks for this fantastic tool! Truly appreciate the effort that goes into it.

[tobysmith568]

Hey @jcfranco,

Thank you for raising this, sorry it's taken us a little while to get back to you.

You mentioned above that you'd be interested in being able to specify a root package.json or an alternative lookup location for license retrieval, however, I was wondering if it would be acceptable for the CLI to automatically traverse up the file system until it finds a node_modules directory?

Assuming the following file:

// ./packages/package-a/package.json
{
  "dependencies": {
    "dep-a": "1.2.3"
  }
}

And the following file structure:

- packages/
  - package-a/
    - package.json    <-- When you pass this file to the generate-license-file CLI as an input...
- package.json
- package-lock.json
- node_modules/    <-- ... It runs up the file tree and finds this node_modules
  - dep-a/    <-- This gets included in the output because it's used in ./packages/package-a/package.json
  - dep-b/    < -- This gets silently ignored because it's assumed to be used by another package in the monorepo

Obviously, we would preserve the existing behaviour where dependencies of dependencies still get discovered; so dep-b would still be included in the output if dep-a depends on it.

Let me know what you think

[jcfranco]

@tobysmith568 No worries and thanks for the reply!

Your proposal sounds great. It addresses our use case and doesn't affect existing API/options. Am I correct to assume this would work for both the CLI and JS API? If so, this is perfect. Thanks!