Mark results as OK, how?

[baruchiro]

So I'm running the lockfile-linter and I get for example these results:

detected resolved URL for package with a different name: string-width-cjs
expected: string-width-cjs
actual: string-width

detected resolved URL for package with a different name: strip-ansi-cjs
expected: strip-ansi-cjs
actual: strip-ansi

detected resolved URL for package with a different name: wrap-ansi-cjs
expected: wrap-ansi-cjs
actual: wrap-ansi

✖ Error: security issues detected!

I research this and I find it because of this package: https://github.com/isaacs/cliui/blob/aa397fedbd0550c9925af6b62f970de663285641/package.json#L52-L57

I don't like it but it seems to be OK.

What should I do to continue enabling the validate-package-names rule and not failed on those packages?

[lirantal]

I'm taking a look, Baruch

[lirantal]

Hah,

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"
  },

and coming from Isaacs, no less 🙃

So, potential ideas here:

1. We can update the package name validator to look at package.json and check for this case of aliasing
2. We can add another flag to allow you to ignore (accept) such cases, on a case by case basis so it will adhere only to the package names that you specify.

Out of these, (1) sounds like a nice way to ease the burden for end users but it also means it couples the lockfile to the package manifest which I don't like. Can you share a simple lockfile that makes use of those package aliases so I can check if the alias is mentioned somewhere else in the lockfile? Also, which version is it?

[lirantal]

@baruchiro see usage: https://github.com/lirantal/lockfile-lint/pull/178/files