Add deps command to return dependencies of a given script/archive

[mstoykov]

What?

Add a deps command.

This does include dependancies that might be needed for building a new binary with auto extension resolution, but also all imports.

Similar to auto extension resolution, this does take into account only imports not require calls.

Why?

This is useful to figure out if a given test will need to build custom binaries as well as look into dependancies in general.

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

Closes #5166

[pablochacin]

I feel the command is exposing too much of the internals that may result more confusing than useful.

For example this command returns the following output from the script below (don't mind if it makes sense to import here, it is to illustrate a point)

I'm not sure how useful the imports section is. And brings some questions: what's the difference between dependencies and imports?

{
 {
  "dependencies": {
    "k6/x/faker": "*"
  },
  "imports": [
    "file:///home/pablo/go/src/github.com/grafana/k6/faker.js",
    "k6",
    "k6/execution",
    "k6/x/faker"
  ],
  "customBuildRequired": true
}

faker.js

import faker from "k6/x/faker";
import exec from 'k6/execution';
import check from 'k6';

export default function () {
  console.log(faker.person.name());
}

[mstoykov]

I've renamed dependancies to buildDependancies as that is what they are. The naming might need to change more, I guess.

But I do prefer to have a way to extract more info like what is imported and this seems to be the correct command for this. We could remove the imports key for now and reintroduce it later when we find a use for it, but I would still prefer to have the structure as is, so we can make that change without breaking it.

[ankur22]

LGTM 🚀 I tested it with a few test scripts and seems to work as expected.

[ankur22]

What's the expected behaviour when the error is a binaryIsNotSatisfyingDependenciesError? Looks like we're just ignoring it. Maybe we should log a debug log if we can ignore it?

[mstoykov]

Here the idea is that if this is the error - this means to run this we need a new binary with som extesnions.

But as we only care about the dependancies and that is already what we've got, here we just check that if this isn't the error, as in that case we need to return it.

[pablochacin]

@mstoykov I see your point. If we are keeping this structure, could we revert the naming back to dependencies, this way it will be consistent with the name in the manifest that we are introducing in #4729 🙏

[pablochacin]

LGTM. I would prefer Dependencies instead of BuildDependencies, as mentioned in another comment. But this is not blocking.

[mstoykov]

I am not aganst it being dependancies but I feel like this is a bit better, I guess lets see what the other reviewers think about it.

[inancgumus]

LGTM, but I think it should be dependencies instead of dependancies.

[codebien]

@mstoykov the CI is failing with errors relavant for this pull request