Check for non-standard NPM registry in package-lock.json as a step in CI

[datho7561]

Having references to the Red Hat internal npm repository in the package-lock.json prevents non-Red Hat developers from installing the vscode-java npm dependencies. As mentioned in #2874 (comment), npm will always use the configured repository to download packages, regardless of what's in the package-lock.json, although it will attempt to validate cached packages against what's in the package-lock.json.

It would be nice to check for the internal repo in package-lock.json as a part of the CI so that in the future we don't accidentally commit changes like this.

[fsouza]

@datho7561 I just ran into this and opened this PR for a one-off removal: #3120.

In terms of checking it, do you have any preferences for the approach? Do you want to be able to point the line number or something like that? Or would a jq/grep powered check work? Something like:

％ cat package-lock.json | jq -r '.dependencies|to_entries[].value.resolved|select(startswith("https://repository.engineering.redhat.com"))'
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/@types/sinon/-/sinon-10.0.13.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/ansi-styles/-/ansi-styles-2.2.1.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/chalk/-/chalk-1.1.3.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/has-ansi/-/has-ansi-2.0.0.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/minimist/-/minimist-1.2.6.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/supports-color/-/supports-color-2.0.0.tgz
https://repository.engineering.redhat.com/nexus/repository/registry.npmjs.org/yargs-parser/-/yargs-parser-5.0.1.tgz

[datho7561]

Thanks for submitting the PR! I'll give it a review.

For the CI step, I think a check using jq or grep would be fine. Once we've identified the issue, it should be easy enough for the PR author to do a find and replace and push an amend, so I don't think reporting the line number or automatically fixing the PR through the job are worth the effort.

[rgrunber]

Thanks for taking the time to fix this up! It should run as part of the verification job now.