Support monorepo and workaround local dependencies

[gladykov]

If you are OK with those changes, I can update documentation and tests.

While trying to use it, I encountered few issues:

1. Some packages define dependencies as paths to files

Ex. "tablesorter": "file:./src/js-vendor/tablesorter" 🤦

a) Such package does not have metadata (name, license). So sorting by name was failing. Added check, to sort only if all packages have names.
b) Lack of metadata was also causing impossible to ignore such packages. Added ignorePath option to ignore by path

2.Reusing licensee() in monorepo in loop over multiple paths to package.json was not working

a) configuration object was kept in memory , meaning it was processed few times, resulting in errors. Now method creates structuredCopy of original, before processing it.
b) It was impossible to wait for licensee() execution, despite method being sync. Marked as async, and now it will return promise, , which at the end returns callback. This allows more custom processing of a result.

Attaching example of TS using this (renamed to txt because Github):
license.txt

[ljharb]

It should probably just omit anything that's a file dep, no?

[kemitchell]

I'd support just ignoring, but I have no idea whether or how Arborist handles such deps.

[ljharb]

Arborist handles them fine, but I mean because it's first-party code so the license isn't relevant.

[gladykov]

Unfortunately we encountered 3rd party package which ships third party packages this way 🤦 So we still had to verify manually if license is OK

[ljharb]

I'm confused, the third-party package contains a file: dep, that's also contained in the package?

and that tablesorter thing has a package.json?

[gladykov]

Say hello to @atlassian/aui package:

where src is hardcoded file:src , and there are internal symlinks between node_modules and src folder

[ljharb]

wow, that is horrific - vendoring code anywhere has been a bad practice for a long time, and doing it in a package is, as this shows, very problematic with tooling, especially security tooling.

In this case, though, the vendored deps don't even seem to have a package.json, so there's no license information to be found - it's useless for this tool (in-code comments aren't statically discoverable). So I still think just unilaterally skipping file deps is the right move.

I also note that I can't even find a live version of that package with tablesorter in it (it may exist, i only checked the latest and earliest in each major, v5-v9). What version are you using?

[gladykov]

We do not use tablesorter. This is dependency coming from the package. Looks like some of those symlinks are even dead

[ljharb]

Right, but that's what i mean - the package doesn't actually have tablesorter in it.

[gladykov]

Yep. Anyway, about PR, should I move forward with docs and tests updates? Any remarks?

[ljharb]

I think a bug fix to not crash with cases like this is great and uncontroversial. I’m not as convinced about a new option.

[kemitchell]

A test inducing a crash would be welcome. Preferably one that writes out a package.json causing the issue, rather than pulling in unrelated packages from npm.

[gladykov]

Added unit test, which proves things will not explode if bad package is added. What I discovered in the process, is that symlink leading to non existing file is causing the issue.

Can you also add filtering by path? It is good for exactly such case.

[gladykov]

Fixed unit test (test was failing because of structuredCopy is not seen by JavaScript Standard Style), and one more corner case we found