feat(packageresolution): add lockfileVersion 2+ packages support

[anas10]

Resolves #393

[julestruong]

good job :) when do you plan to merge this ?

[orta]

Cool - did you verify it works @julestruong?

@anas10 it'd be great to get an integration test for this, because I don't know enough about npm's lock files to know if it is correct: https://github.com/ds300/patch-package/tree/master/integration-tests (and to make sure no-one breaks it further down the line)

[julestruong]

I used patch package and yes it works

[anas10]

@orta Good shout, I've now added some integration tests for every version of lockfile.

[anas10]

Tests updated. I've made sure that they were not false positives.
Tests fail as expected without the code change and succeed consistently with the code change ✅

[orta]

Perhaps this syntax is only available on your machine and not on CI? Assuming you're using a mac, it defaults to zsh - and I bet CI defalts to bash

[anas10]

That's odd. This is a fairly standard syntax 🤔
I've made a small change, can you trigger now to see. If not, I'll just repeat the test 3 times without the function.

[orta]

No idea why - but I think we might need this on CI, grover/homebridge-dacp#66 (comment)

[iTonyYo]

Why not just judge by lockfileVersion？

const lockfile = require(path_1.join(appPath, packageManager === "npm-shrinkwrap"
    ? "npm-shrinkwrap.json"
    : "package-lock.json"));

if (lockfile.lockfileVersion > 2) {
    return Object.entries(lockfile.packages).find(el => el[0].includes(packageDetails.name))[1].resolved;
}

const lockFileStack = [lockfile];
for (const name of packageDetails.packageNames.slice(0, -1)) {
    const child = lockFileStack[0].dependencies;
    if (child && name in child) {
        lockFileStack.push(child[name]);
    }
}

lockFileStack.reverse();

const relevantStackEntry = lockFileStack.find((entry) => entry.dependencies && packageDetails.name in entry.dependencies);

const pkg = relevantStackEntry.dependencies[packageDetails.name];
return pkg.resolved || pkg.from || pkg.version;

[rokiyama]

@anas10 Just delete #!/usr/bin/env bash and CI will succeed. Alternatively, changing it to #!/bin/sh will also work.

This is because bash does not expand aliases when in non-interactive mode and shopt expand_aliases is not set.

succeed:

#!/bin/sh
alias my-command='echo hello'
my-command

# => hello

fail:

#!/bin/bash
alias my-command='echo hello'
my-command

# => line 3: my-command: command not found

[rokiyama]

Other problems:

While not critical, it might be a good idea to install [email protected].

Now lockfile v2 and v3 work. However, v1 still does not work.

npm i --lockfile-version 1 produces error: ... /src/mdns.hpp:31:10: fatal error: dns_sd.h: No such file or directory.

To fix this, adding sudo apt install libavahi-compat-libdnssd-dev to main.yaml results in another error: ... /src/mdns_utils.hpp:14:5: error: 'Handle' in namespace 'v8' does not name a template type

I don't know how to resolve this. As a workaround, we can avoid the CI error by deleting the lockfile v1 test.

How I fixed it: https://github.com/Threestup/patch-package/pull/1/files

[rokiyama]

@orta Tests are updated, can you retrigger the tests?

[orta]

This PR looks good!

I'm not at my main computer for 2 weeks, so I can't really handle the merge conflict for you - it should probably be automatic, it's changing a line next to one of your changes. If you get that fixed, I'll merge the PR and get a release sorted!

[anas10]

@orta I've resolved the conflicts. Thanks for checking

[orta]

Thanks everyone! Looks good to me

[ds300]

Released in v6.5.1, thanks for the contribution 🎉 ❤️