Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages from NPM workspace reported as dependencies #415

Open
tsmaeder opened this issue Nov 22, 2024 · 4 comments
Open

Packages from NPM workspace reported as dependencies #415

tsmaeder opened this issue Nov 22, 2024 · 4 comments

Comments

@tsmaeder
Copy link

tsmaeder commented Nov 22, 2024

I have a package.json with multiple workspaces in them, having for example a package at sample-plugins/sample-namespace/sample-plugin (see below). I do an npm install, producing a package-lock.json. When I run dash-licenses against the package-lock.json, the package at sample-plugins/sample-namespace/sample-plugin is reported as a dependency that needs to be IP-Checked.
My expectation would be that packages that are part of the repo are not reported as dependencies. This is also what happens when I use yarn.lock for the same repo.

@tsmaeder
Copy link
Author

package-lock.json

@tsmaeder
Copy link
Author

When I change the name of the package to @theia/plugin-a in the package.json, the package is no longer reported as a dependency.

tsmaeder added a commit to tsmaeder/theia that referenced this issue Nov 22, 2024
@waynebeaton
Copy link
Collaborator

Trying to parse the package-lock.json file from Java has been challenging. Not least because I just don't have the resources to really dig into and understand the format. The current implementation does recognise some content as "project content", but getting it completely right has been difficult. It's not clear to me, for example, how to handle wildcards in the workspace list (e.g., is packages/* intended to match both packages/terminal and packages/task/node_modules/async-mutex, or just the former?).

Regardless of whether or not we have an answer to that question, my thinking is that it's better to (re)focus the Eclipse Dash License Tool on what it does well and leverage NPM features to get the list of dependencies. That is, my thinking is that we should deprecate and eventually remove this functionality rather than try to maintain currency with a format that we lack resources to understand and maintain. Likewise for the yarn.lock file reader.

The npm ls command does, I believe, give us a proper listing of what's installed, so we have that. Any modules that get listed in error can be removed via CLI before piping to the licence tool.

It's handy (at least for the EMO) to be able to parse a package-lock.json file out of context, but I'm not aware of any tools that do that. @tsmaeder are you aware of any native NPM tools that can help here?

@tsmaeder
Copy link
Author

@waynebeaton unfortunately I don't know...just converting our project to the wonderful world of npm myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants