RSeidelsohn / license-checker-rseidelsohn

Extract NPM package licenses. Enhanced and updated fork of Dav Glass' original but abandoned license-checker.
https://www.npmjs.com/package/license-checker-rseidelsohn
Other
122 stars 32 forks source link

Workspaces support #36

Open GMaiolo opened 2 years ago

GMaiolo commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

restfulhead commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

restfulhead commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

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

Schneider1 commented 1 month ago

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.