[lockfile-explorer]Add version validation capability

[L-Qun]

Summary

Our team currently has a requirement to analyze whether the dependency tree contains multiple versions of a target package, so I have implemented this feature into lockfile-explorer.

Details

In this PR, I have introduced an additional dependency on yargs to parse arguments. At the same time, we have added new commands lockfile-lint and lflint to verify whether the project complies with the rules specified in the lockfile-lint.json file.

How it was tested

Manually tested with Rushstack repo locally.

Impacted documentation

@william2958

[octogonz]

Could you add a test that makes a Jest snapshot of the CLI help? Otherwise it's difficult for code reviewers to review it.

lockfile-explorer [command]

Commands:
  lockfile-explorer check                   Check if the specified package has a
  <package-specifier>                       inconsistent package versions in
                                            target project
  lockfile-explorer start                   Start the application

Options:
  -h, --help     Show help                                             [boolean]
      --version  Show version number                                   [boolean]

lockfile-explorer check <package-specifier>

Check if the specified package has a inconsistent package versions in target
project

Positionals:
  packageSpecifier  The name of the package and version to check        [string]

Options:
  -h, --help     Show help                                             [boolean]
      --version  Show version number                                   [boolean]
      --project  The name of the project that should be checked         [string]

etc.

[L-Qun]

done😊

[octogonz]

The website will definitely need to be updated to document this CLI

[octogonz]

Our team currently has a requirement to analyze whether the dependency tree contains multiple versions of a target package, so I have implemented this feature into lockfile-explorer.

@L-Qun This sounds somewhat related to the earlier Design Proposal: Lockfile Lint which @william2958 prototyped in #4094

🤔 Besides checking "Does this project's dependency tree include multiple copies of react?", it's easy to imagine lots of other problems that could be detected with similar "checks."

And the UX has several possible approaches:

1. Web app: The checks can be performed via commands in the Lockfile Explorer web app
2. Manually invoked shell command: The checks can be performed by invoking a CLI like lockfile-explorer check
3. Lockfile Lint: The checks could be defined/customized in JSON config files, and then enforced automatically by a CI pipeline.

(In fact, it would be possible to provide all 3 approaches for each check.)

So your PR seems like a good idea, but I wonder if it maybe it could be a bit more flexible, or build on the Lockfile Lint design.

[L-Qun]

The website will definitely need to be updated to document this CLI

Do you mean to update the content here? https://github.com/microsoft/rushstack-websites/blob/main/websites/lfx.rushstack.io/docs

[L-Qun]

Our team currently has a requirement to analyze whether the dependency tree contains multiple versions of a target package, so I have implemented this feature into lockfile-explorer.

@L-Qun This sounds somewhat related to the earlier Design Proposal: Lockfile Lint which @william2958 prototyped in #4094

🤔 Besides checking "Does this project's dependency tree include multiple copies of react?", it's easy to imagine lots of other problems that could be detected with similar "checks."

And the UX has several possible approaches:

1. Web app: The checks can be performed via commands in the Lockfile Explorer web app
2. Manually invoked shell command: The checks can be performed by invoking a CLI like lockfile-explorer check
3. Lockfile Lint: The checks could be defined/customized in JSON config files, and then enforced automatically by a CI pipeline.

(In fact, it would be possible to provide all 3 approaches for each check.)

So your PR seems like a good idea, but I wonder if it maybe it could be a bit more flexible, or build on the Lockfile Lint design.

I think making the lockfile-explorer tool better is a long-term process. Perhaps we can first merge this PR after I update the documentation, and then I will gradually iterate and optimize it.