Conversation
|
Is this still the case with arborist 6, which will be in v10 of licensee? |
|
Sorry, missed that comment! I just checked using {
"name": "licensee-playground",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"@npmcli/arborist": "^6.2.7",
"mit-licensed": "^1.0.0"
}
}const Arborist = require('@npmcli/arborist');
const arborist = new Arborist();
arborist.loadActual({ forceActual: true }).then((tree) => {
const dependencies = Array.from(tree.inventory.values()).filter(
(dependency) => !dependency.package.name
);
console.log(dependencies.length); // 108
}); |
|
Hmm - thinking about this more, the |
|
Is licensee even choosing directory targets? Isn't it just calling Arborist in CWD? Ideally we shouldn't care about npm versus yarn versus pnpm or any other thing-that-populates-node_modules. We should fire Arborist off at node_modules and go from there. We'd have to reconsider Arborist, or using Arborist alone, if Arborist decided to support just the way npm does node_modules, but not other ways that Node.js says it can be done. I haven't seen any sign of that yet. |
|
That's a good point, and I agree - this may be a bug in arborist, in which case that's where it should be fixed. |
|
@ljharb , can we get this fix merged and released? |
|
@jayvdb, this was identified as an issue, if at all, with Arborist, a dependency of Licensee. Are you aware of any developments in Arborist or the use of |
|
So far all I know is that this PR fixes the problem with using licensee with pnpm. I dont know whether there is a bug or not in Arborist. I do know the problem in licensee with pnpm was not fixed with this commit 54a22a2 https://www.npmjs.com/package/@npmcli/arborist is now at v7.5.4 |
|
Updating aborist to v7.5.4 didnt fix the problem |
|
No worries, was just rebasing. I’ll leave merging to you when you’re ready :-) |
|
Sounds like fair karma. For what it's worth, a number of deps are out of date, including Arborist. A few thoughts there:
|
|
a thorough CI matrix, combined with an i 100% agree about pnpm-speciifc; either arborist should handle it, or pnpm (or yarn, etc) should fix it. |
|
Firstly, this is not a bug in pnpm. It has a different layout in Also, it does not appear to be a problem in arborist. They have copious tests covering pnpm. c.f. https://github.com/search?q=repo%3Anpm%2Fcli%20pnpm&type=code There isnt good docs for how arborist describes pnpm/yarn managed package trees, and for that I have created npm/cli#7765 When using arborist with pnpm managed node_modules, it returns items like the following two which are correctly handled by licensee.js However arborist also includes items like the following which licensee.js does not understand. This PR fixes licensee.js so that it correctly skips these entries that it doesnt need to process. |
|
Having a different layout often is a bug in and of itself - altho in this case, it seems like something licensee should indeed be updated to handle. |
|
@cvx , any chance you could rebase this so we can see whether CI passes now. CI is green on |
`@npmcli/arborist` (incorrectly?) returns dependencies with no package info when looking in `/node_modules/.pnpm` directory. It does also return correct data from deeper nested dirs like for example `/node_modules/.pnpm/tmp@0.2.1/node_modules/tmp` so we can just ignore the invalid entries.
|
All green and no conflicts again! |
|
Note https://github.com/google/osv-scanner now supports scanning pnpm lock files for licenses. c.f. https://google.github.io/osv-scanner/experimental/license-scanning/ . It lacks the features of licensee.js , and is Go rather than JS, but it may be sufficient for some people who are waiting for this PR to be merged. |
@jayvdb, do you know what those ArboristNode entries are meant to represent? Why is it proper to simply ignore them? |
|
You can inspect them using the |
|
@jayvdb, I imagine delay on this PR might feel frustrating, since the functional fix here is just a half-line patch to a boolean check. Please do know that you're not going to irk any of the maintainers around here by pushing and running a fork for your own purposes, at least until this is resolved. We might be feeling some of the same frustration elsewhere, too, in dealing with collateral consequences of the npm team moving Arborist into a workspace of the CLI. It's no longer quite as clear to me that they want to spend the effort to make the My concern is that I don't know what ignoring dep-nameless result nodes could cause, apart from hushing errors on pnpm Digging into that is a lot of work, which I don't expect to simply throw back on you or anyone else. Perhaps an interim solution could be to add a |
|
nodes without names are part of Arborist API. I personally dont see the need for a command line flag, but if it helps move this forward I propose |
|
The only relevant doc I could find was in Arborist's
|
|
It would be great if this was merged, then I could actually use this for my project. |
|
For reasons I have earlier, I'm reluctant to add a change of logic to "fix" analysis of pnpm dependencies that we don't understand the other rammifications of. This package doesn't generally claim pnpm support. pnpm does things strangely, deviating from the Node spec and conventions. I don't want to end up chasing pnpm's behavior, however it may further deviate in the future. |
I understand. But then I would like to suggest being more transparent about licensee's pnpm support and clearly state that pnpm is not supported. It doesn't matter why (or who's fault it is). By not clearly stating that pnpm is not supported and by keeping this PR open with no intent to merge it, you implicitly do claim pnpm support from my point of view. |
|
"not npm" not being supported never needs to be stated; it's the default for the ecosystem. However I agree that keeping this PR open implies that pnpm is intended to be supported. |
5 participants
@npmcli/arborist(incorrectly?) returns dependencies with no package info when looking in/node_modules/.pnpmdirectory.It does also return correct data from deeper nested dirs like for example
/node_modules/.pnpm/tmp@0.2.1/node_modules/tmpso we can just ignore the invalid entries.