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

Approval needed for not-installed Yarn package #456

Closed
grantbdev opened this issue Jan 24, 2018 · 3 comments
Closed

Approval needed for not-installed Yarn package #456

grantbdev opened this issue Jan 24, 2018 · 3 comments

Comments

@grantbdev
Copy link
Contributor

I am developing locally on OS X with Webpack(er), which has an optional transitive dependency on OS X exclusive package fsevents. yarn install installs it and License Finder thinks it is OK probably because I have whitelisted MIT licenses.

However, on the Travis CI build using Linux:

yarn install v1.3.2
...
info fsevents@1.1.3: The platform "linux" is incompatible with this module.
info "fsevents@1.1.3" is an optional dependency and failed compatibility check. Excluding it from installation.
...
bundle exec license_finder --quiet

Dependencies that need approval:
fsevents, 1.1.3, unknown

So it would appear that due to the package being excluded/not fully installed due to incompatibility, the license information is still checked for approval but not found correctly.

I have resolved the problem by adding a dependency approval specific to the fsevents package, but I would expect License Finder to either (a) ignore the package when it is excluded or (b) still be able to find the license information like it does locally when the package is compatible and installed/included.

This is with license_finder 5.0.0.

@kdykeman
Copy link
Contributor

kdykeman commented Jan 25, 2018

@grantbdev Unfortunately, there isn't an easy fix for this one. LicenseFinder is relying on the output from yarn licenses list to obtain the applicable license. yarn licenses list gets the license and url information from inspecting the package.json files installed in the local node_modules folder. Since yarn cowardly refuses to install incompatible modules, the license information isn't readily available.

So tackling the options you raised:

a) It seems better if LicenseFinder exercises this pessimistic behavior rather than ignoring packages because they're not used on the current build platform. As an example, if you weren't running LicenseFinder locally and instead relying on your CI system to flag issues (not an uncommon use case), and if instead of fsevents, you were using an optional package that was not MIT licensed, the potentially problematic dependency would never be flagged.

b) In order to still find the license information, there would either need to be an upstream patch to yarn to "install --bravely" incompatible modules, or something would need to be implemented in LicenseFinder that reproduced the yarn install behavior. The second option is a pattern that doesn't exactly fit with the LicenseFinder paradigm of getting information from package managers and their associated files.

The best options seem to be either looking into the "install --bravely" option, or addressing it as you mentioned, by explicitly approving the dependency by name and possibly version.

I'll add a known issues section to the README prior to closing this issue.

@kdykeman
Copy link
Contributor

Added commit 785c07b referencing this GitHub issue.

@hibachrach
Copy link

I don't know if this is still true? Running yarn licenses list --recursive --ignore-platform does yield all packages, regardless of the current platform (using Yarn 1.22.5). I would request that this is reopened (or I could open another issue).

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

3 participants