fix: Cannot read properties of undefined (reading 'description')

[vrubezhny]

A check for not defined node.package value is added to getHumanOutputItem

References

Fixes: #5961

[wraithgar]

I don't think this is a problem we should just if-statement around. If node doesn't have a package attribute either it's an underlying bug, or it's a node type we're not properly handling.

[vrubezhny]

The problem happens with optional/week dependencies that aren't really installed, f.i., for the ws@8.11.0 dependency from the issue - it optionally depends on:

  "peerDependencies": {
    "bufferutil": "^4.0.1",
    "utf-8-validate": "^5.0.2"
  },

these modules are not installed by default when using npm install --no-bin-links --ignore-script command.
As such, a reference to these modules exist (from ws module's package-lock.json), but no bufferutil/utf-8-validate package.json/package-lock.json files available. to make it possible to read a description or other information for these modules.

[12Me21]

This can happen even if packages are installed "normally" (i.e. using npm install without any options), if an optional dependency doesn't exist or isn't supported.

For example, try npm install rollup, then npm ll rollup.
(It fails on most platforms because rollup has an optional dependency on fsevents, which is only available for macOS.)

[pniederlag]

I don't think this is a problem we should just if-statement around. If node doesn't have a package attribute either it's an underlying bug, or it's a node type we're not properly handling.

@wraithgar this is indeed a problem, at least for anyone running "npm ls --long" as it is failing in numerous cases. While I don't have a clue on the root-cause of the problem it should at least be clearified when an where "npm ls --long" breaks und how one can get around it if this patch/pr is not the properly adressing the issue.