myndzi
myndzi
I wrote that tool for exactly that reason, but I'm currently struggling with a few problems with `nlf` and the spdx database in general, as an alternate to `nlf`'s file...
Uncertain what you mean? for `node-license-validator`, you specify up front what licenses are allowed, and, in the case of specific package exceptions (perhaps to deal with licenses that aren't detected...
One problem you will encounter immediately is that many published packages do not have valid SPDX licenses in their package.json, even if they have valid SPDX licenses. Deeper validation should...
> If we can't get a PR fixing one of our dependencies invalid license out, then I don't think it's a package we want to use. I can't quite understand...
(This list does not include _dependents_ of these modules, of which there are many)
I'm using nlf primarily in order to take advantage of its file results; my spdx matcher was not usable at the time, and still really isn't, and I was frustrated...
It's not broken per se, it just doesn't offer as solid of a guarantee as I'd like, given the behavior of its dependency `nlf`. We're discussing what might be done...
I can implement deep inspection easily (it's just an argument I'm passing to nlf anyway) As for 2, I can implement the ability to specify what kind of matches are...
How do you guys feel about development dependencies? I'm doing some testing, and I find that, recursively, one of my largest projects has 397 dependencies if I count only direct...
Makes sense, and is the only sensible solution.