fix: throw 'not implemented' error in buildDepTree for npm v2/v3 lockfiles

[milahu]

• Tests written and linted
• Documentation written / README.md updated https://snyk.io/docs/snyk-for-node/
• Follows CONTRIBUTING agreement
• Commit history is tidy https://git-scm.com/book/en/v2/Git-Branching-Rebasing
• Reviewed by Snyk team

What this does

throw not implemented error in buildDepTree for npm v2/v3 lockfiles

better than OutOfSyncError from getDependencyTree

OutOfSyncError: Dependency @cycle/http was not found in package-lock.json. Your package.json and package-lock.json are probably out of sync. Please run "npm install" and try again.
    at PackageLockParser.getDependencyTree (node_modules/snyk-nodejs-lockfile-parser/dist/parsers/lock-parser-base.js:124:27)
    at async PackageLockParser.getDependencyTree (node_modules/snyk-nodejs-lockfile-parser/dist/parsers/package-lock-parser.js:28:32)
  code: 422,
  dependencyName: '@cycle/http',
  lockFileType: 'npm7'

problem in PackageLockParser.getDepMap:
packageLock.dependencies is undefined, it should use packageLock.packages

nodejs-lockfile-parser/lib/parsers/package-lock-parser.ts

Line 110 in 103bb2d

flattenLockfileRec(packageLock.dependencies || {}, []);

so the not implemented error is thrown in getDepMap before calling flattenLockfileRec

to implement support for v2/v3 npm lockfiles, a good place would be getDepMap

  protected getDepMapV2(packageLock: PackageLock): DepMap {
    // TODO implement
  }

  protected getDepMap(lockfile: Lockfile): DepMap {
    const packageLock = lockfile as PackageLock;

    if (packageLock.lockfileVersion == 2) {
      return this.getDepMapV2(packageLock);
    }

Notes for the reviewer

low priority

[calderonth]

Does that mean that currently calling buildDepTree is expected to fail for npm v2/v3 lockfiles?

[milahu]

yes, see the readme

This is a small utility package that parses lock file and returns either a dependency tree or a dependency graph. Dependency graphs are the more modern data type and we plan to migrate fully over.

Dep graph generation supported for:

• package-lock.json (at Versions 2 and 3)
• yarn.lock

Legacy dep tree supported for:

• package-lock.json
• yarn 1 yarn.lock
• yarn 2 yarn.lock

[calderonth]

ok so say for the time being I wanted to cover all manifest version I would have to add logic in order to detect manifest/lockfile types/versions and then call either dep-graph or dep-tree?

[milahu]

yes, thats what im doing in my pnpm-install-only

  const lockfileContent = read(lockfilePath);
  const lockfile = JSON.parse(lockfileContent);

  const [deps, walk_deps] = (
    lockfile.lockfileVersion == 3 ? await getDepgraph(lockfilePath) : // TODO verify
    lockfile.lockfileVersion == 2 ? await getDepgraph(lockfilePath) :
    lockfile.lockfileVersion == 1 ? await getDeptree(lockfilePath) :
    [null, null]
  )

  if (deps == null && walk_deps == null) {
    throw new Error('failed to recognize the lockfile type');
  }

edit: see also my parse-package-lock

[calderonth]

Right, I thought I could use this as a somewhat universal library to parse various lockfile format, so in top what you're doing you'd have to have edge cases for Yarn lockfiles which aren't JSON?

EDIT: I realise you have that logic backed into your code so I might get some inspiration from you :-)

[milahu]

yarn lockfiles are not-yet handled by my code

other limitations of snyk-nodejs-lockfile-parser:

• pnpm lockfiles are not supported, see Add pnpm support? #111
• resolved and integrity values are not returned, see add fields resolved and integrity to deptree and depgraph #199

[github-actions]

Your PR has not had any activity for 60 days. In 7 days I'll close it. Make some activity to remove this.

[github-actions]

Your PR has now been stale for 7 days. I'm closing it.