The CI fail looks to be because of a different vulnerability in the dependency tree, this time with yargs-parser. It requires a new version of @commitlint/cli to be released first (see conventional-changelog/commitlint#1691).

Thanks, I'll take a look at this in more depth later this week.

@shellscape have you had time to look at this yet? It would be good to get this released so I can then move on to updating packages that depend on this package (which will be needed if this is going to be a major version bump).

So we won't be able to merge this because a protocol-relative uri is still a valid uri in the CSS realm. Using

.foo { background: url(//mysite.example.com/mycursor.png); }

and https://jigsaw.w3.org/css-validator/#validate_by_input, we can see that it's still valid. Just changing the test snapshots won't do, as they're incorrect. I've opened this issue sindresorhus/is-url-superb#6 with is-url-superb in the mean time.

npm audit still doesn't identify this as a high vulnerability, and as this is only intended to be used in a toolchain in a dev environment, any DoS would be self-inflicted. For all of these reasons, I have to pass on this PR. I do appreciate the time and attention you've given to it, however.

No problem, that makes sense.

It looks like is-url-superb just uses the Node.js URL class to determine if a URL is valid. So I'm not convinced that is-url-superb should be changed, given that it is a Node.js package and not concerned with CSS. It's this package (postcss-values-parser) that wants CSS compatibility, so perhaps the URL check should be implemented in this package? It's easy enough to do a check with the URL class for the majority of URLs anyway (not sure is-url-superb is really needed...) and then would just need to add an extra check for protocol-relative URLs.

Yeah it was definitely used as a convenience. I'm up for removing it if there's an equivalent solution in place.

Welp. Sindre is saying that because it's considered an anti-pattern by some influential people, that he's not going to support it. That doesn't change the fact that all of the vendors still support it and that it's still valid per CSS spec. So we'll have to drop that package in favor of another solution unfortunately.

I'm afraid putting together a pull request to replace the dependency is not something I feel confident doing; I'm not a JavaScript developer!

I'll create an issue to track this and hopefully someone can look at it.

Yes please do create that issue. I'll try to get to it sooner rather than later.