[Feature] archiveUrl in logs leads to lengthy and difficult to read output

[mskelton]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin (I'm new to contributing, so I'm not sure)

Describe the user story

I've recently began updating a few projects to Yarn 2 and while I really like the improvements, one thing that has been a big pain point is the __archiveUrl of packages being output in the logs. My company uses a private npm registry and so a large majority of installed packages will have this tacked on to the end of the logs. This results in output that looks similar to this:

➤ YN0041: │ @company/package-a@npm:10.11.0::__archiveUrl=https://company.registry.com/company/api/npm/npm-virtual/@company/package-a/-/@company/package-a-10.11.0.tgz: Invalid authentication (as an anonymous user)
➤ YN0041: │ @company/package-b@npm:10.11.0::__archiveUrl=https://company.registry.com/company/api/npm/npm-virtual/@company/package-b/-/@company/package-b-10.11.0.tgz: Invalid authentication (as an anonymous user)
➤ YN0041: │ @company/package-c@npm:10.11.0::__archiveUrl=https://company.registry.com/company/api/npm/npm-virtual/@company/package-c/-/@company/package-c-10.11.0.tgz: Invalid authentication (as an anonymous user)
➤ YN0041: │ @company/package-d@npm:10.11.0::__archiveUrl=https://company.registry.com/company/api/npm/npm-virtual/@company/package-d/-/@company/package-d-10.11.0.tgz: Invalid authentication (as an anonymous user)

In our CI pipeline, these logs will often wrap creating very unreadable output. We have quite a few logs right now as we are working on fixing peer dependency issues in our packages and other issues, but I could see this being a pain point for other new users who are starting to make the transition to Yarn 2.

Describe the solution you'd like

Having an option to disable printing the c in the logs or remove it entirely. I would lean towards an option as I could see value in having it when debugging where packages are attempting to be installed from.

Describe the drawbacks of your solution

More options means more combinations to test. Also, how would this option be named to be clear and not confuse users? Especially since this really only applies to packages from private registries that I can tell.

Describe alternatives you've considered

Dealing with the logs and calling it a day. I waffled on whether to open this issue, but figured it would be helpful to at least have the discussion.

[arcanis]

This __archiveUrl is necessary for registries that don't follow the standard url patterns from the npm registry:

<npmRegistryServer>/<name>/-/<name>-<version>.tgz

We could perhaps hide it from the printed logs, but it would have a slight performance impact on every printed locator, I'm not sure it'd be worth it ... I agree it's ugly, though 😕 Any chance you could open an issue on your private registry's tracker to let them know?

[mskelton]

Ah I see. I didn't realize it was due to a URL pattern issue so I'll definitely follow that lead with our private registry. Definitely don't want this to be something that would decrease performance, so I'll go ahead and close this issue. Thanks for the help!

[merceyz]

You can probably use the logFilters to filter them out or preferAggregateCacheInfo to reduce the amount of lines logged

[mskelton]

Hmm, so perhaps I jumped the gun on closing this issue. Our urls looks like this:

https://scope.jfrog.io/scope/api/npm/npm-virtual/@scope/package-a/-/@scope/package-a-1.1.0.tgz

and my .yarnrc.yml file looks like this:

npmRegistryServer: https://scope.jfrog.io/scope/api/npm/npm-virtual
npmAuthIdent: '...'

And yet, when I install a package I get the following output:

➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0013: │ @scope/package-a@npm:1.1.0::__archiveUrl=https%3A%2F%2Fscope.jfrog.io%2Fscope%2Fapi%2Fnpm%2Fnpm-virtual%2F%40scope%2Fpackage-a%2F-%2F%40scope%2Fpackage-a-1.1.0.tgz can't be found in the cache and will be fetched from the remote ser
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: Done in 0s 111ms

Are the %2f and other character representations in the logs expected? Or is that perhaps part of the issue here? Translating those characters to their real value the url is the following which matches your comment for what it should look like:

https://scope.jfrog.io/scope/api/npm/npm-virtual/@scope/package-a/-/@scope/package-a-1.1.0.tgz

[arcanis]

We support both %2f and / (funny story 😛) - the problem is that on the npm registry the scope isn't repeated in the tarball name (only the name itself is). So it should be like this for us to be able to infer the archive url:

OK: https://scope.jfrog.io/scope/api/npm/npm-virtual/@scope/package-a/-/package-a-1.1.0.tgz
KO: https://scope.jfrog.io/scope/api/npm/npm-virtual/@scope/package-a/-/@scope/package-a-1.1.0.tgz

[mskelton]

Oh interesting. So the scope should only be present in the first chunk but not after the /-/. Didn't realize that was a thing 🙂 Learning a lot today!