Warnings due to @qiwi/npm-registry-client used in utils package

[kirtan-desai]

What is the purpose of using npm-registry-client? Is there any plan to deprecate its usage? The use of request library in @qiwi/npm-registry-client is causing warnings upstream.

[kamontat]

I would like to follow up on this as well.
@sandersn @jakebailey @andrewbranch

[sandersn]

npm-registry-client is used for publishing and updating tags. It's not needed for dtslint, dtslint-runner or eslint-plugin, the parts that run in CI.

1. What are the warnings? Can you link to one?
2. What is 'upstream'? Are you depending on rules from @definitelytyped/eslint-plugin?
3. Is there an alternative to use? I remember somebody mentioning it but we were in middle of lots of other work on dt-tools at the time.

[jakebailey]

It's a dep of the util package since it's used both in the publisher and in retag.

I've been meaning to send a PR to switch everything over to pacote or libnpmpublish by reviving #472 which is conflicted (but didn't finish the rebase before the holidays)

[jakebailey]

I do think we should make some sort of "internal utils" package to hold shared code for our non published packages, as that'd minimize these sorts of problems. (Then again the only people that should see this message are those depending on our packages outside of DT which we don't yet officially say is a good idea)

[kamontat]

@jakebailey I'm not sure what the original problem @kirtan-desai was.

Describe

For me, @qiwi/npm-registry-client contains 2 problem dependencies: request which contains tough-cookie. Both dependencies contains vulnerability (here and here). Even though it might not effect but I would like to mitigate potential issues as well as @qiwi/npm-registry-client didn't release any new version in past 3 years.

How

I currently use @definitelytyped/eslint-plugin to lint internal @types packages. and it use utils internally.

[Lusito]

I do think we should make some sort of "internal utils" package to hold shared code for our non published packages, as that'd minimize these sorts of problems. (Then again the only people that should see this message are those depending on our packages outside of DT which we don't yet officially say is a good idea)

Here's an example why I have this issue as a non-internal developer:
I'm the author of @types/webextension-polyfill, which is a project, that is entirely generated from schema files. Having the eslint-plugin within my project allows me to check for linting issues way ahead of creating a DT pull request.