Approval needed for not-installed Yarn package
grantbdev opened this issue · 3 comments
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.
@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.
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).