Workspaces support

[GMaiolo]

Been trying to get this to work with a monorepo with workspaces and it's impossible to use the --production flag as it yields empty results. It's also not possible to navigate to each project and run the license-checker as the node_modules folder is empty in these directories.

In such environments, each workspace has its own package.json but the node_modules is located on the root and shared between these workspaces.

Does anyone know if a workaround is possible with this setup?

[codepunkt]

What's the point of the --production flag anyways? Do you realize that this usually gives you a lot of false positive licenses that are not included in your build output and thus not distributed? Do you understand why this also might give you a few false negatives, missing the licenses of packages that you are distributing?

[GMaiolo]

What's the point of the --production flag anyways? Do you realize that this usually gives you a lot of false positive licenses that are not included in your build output and thus not distributed? Do you understand why this also might give you a few false negatives, missing the licenses of packages that you are distributing?

@codepunkt Are you asking what the production flag's point is in my specific scenario or in the library as a whole?
I don't remember what I was trying out at that time (it's been a few months), but I assume I wanted to ignore all internal tooling security issues.

Disregarding the production flag discussion, workspace checks still yield incomplete results.

[codepunkt]

@GMaiolo Are the packages/workspaces in your monorepo being built with webpack, rollup or other bundlers?

[restfulhead]

Hi. I'm facing the same issue. As a workaround I'm running the check now from the root of our monorepo. But of course that then reports on all dependencies. It would be nicer to be able to run this within each NPM workspace.

@codepunkt We don't use any bundlers, just plain NPM workspaces

[RSeidelsohn]

Hi @restfulhead , @fredrikaverpil just pointed me to this issue - sorry for the delay; this is not a well-maintained repo, as I rarely find enough time to care for it, but it's not abandoned as well.

I never heard of npm workspaces before reading about it here and first have to read and understand the documentation. It looks like an important feature, supporting npm workspaces, as probably more and more people will use them.

So I'd love to hear from you:

How would you expect or want license-checker-rseidelsohn (sorry for the clumsy name) to behave when it is run on npm workspaces? Should it run on all workspaces and separate the output per workspace?

Cheers and thank you for your input, Roman.

[fredrikaverpil]

I'll let others chime in as I'm not a js/ts/node expert, but I was hoping to implement a license checker in our company and we sometimes make use of npm workspaces for repos that hosts multiple packages.

• This seems to work okay when $cwd is at the root package.json and package-lock.json. I'm hoping that sometime in the future be able to search for all package.json files in a repo, and then cd into that folder and run this license check tool there (regardless of using npm workspaces or not). But that does not work currently, when a package.json is part of an npm workspace.
• When using npm workspaces, I've noticed that the root package.json (which does not have a license key by default) acts up, mentioned in Licensed under "Custom: https://github.com..." #63, but can mitigated by adding the license key/value into the root package.json .

[restfulhead]

Thanks for considering this issue.

Basically I'd like to be able to run the checker inside each workspace and then it would report the licenses of all dependencies just for that workspace.

For example if I have the following package.json inside a workspace:

"scripts": {
    "license-checker": "npx license-checker-rseidelsohn"
}
"devDependencies": {
    "license-checker-rseidelsohn": "4.1.1"
}

Then I'd like to be able to run npm run license-checker -w my-workspace and have it report only relevant dependencies.

It currently seems to run, but not reporting the correct licenses. Keep in mind that with this setup, there is no package-lock.json file or node_modules directory in each workspace; only one at the root.

[RSeidelsohn]

Hello @restfulhead, @fredrikaverpil, @codepunkt and @GMaiolo,

I will most likely start working on this feature in two weeks (my new employer allows me to work on my OS project every 2nd friday). I finally had a look at the docs and played around with the new workspaces feature and think I understand it good enough in order to add a feature for it. But it of course might be that this will become complicated once I start doing it, so I can't promise what the feature will look like exactly or when it might be ready.

Cheers, Roman.

[RSeidelsohn]

Hello folks, thanks to @AgentOren, who provided a bugfix PR to the read-installed-packages module and then merged the new version 2.0.1 into this module, this issue should now be fixed finally! Awesome.
Also thanks to @Semigradsky, who merged Oren's PR and provides the new 2.0.1 version.

[huschu]

This would be a great addition! Are there any updates on this?

[Schneider1]

For me it looks as if read-installed-packages would need better support for workspaces first. It seems that this package always looks for the package.json and node-modules in the same folder. For a workspace however, it would be ./my/workspace/package.json deeper down and ./node-modules on top level.

if you run the licence checker in the workspace, it would find the ./my/workspace/package-json, but no modules; If you run it on top level, it would actually find all your dependencies, but report all which are not in your top level ./package.json as extraneous. This means in turn, that if you use --production, only the packages in your top-level ./package.json are scanned.

[seantimm]

It can be more complicated than that as you can have workspaces that end up with a node_modules folder as well as the root path with one (depending on version dependencies).