[feat] yarn audit fix

[nickmccurdy]

Related to #5808 (yarn audit)

Do you want to request a feature or report a bug?

feature

What is the current behavior?

yarn audit fix does the same as yarn audit and doesn't actually fix known vulnerabilities.

What is the expected behavior?

It should behave like npm audit fix and update packages to safe versions where possible. Another report should be displayed after upgrading packages if there are still vulnerabilities that have to be fixed manually.

Unfortunately npm audit fix can't be used directly with yarn because it requires an npm lockfile, which would have different dependency versions than yarn's lockfile. There should be some APIs available though, as there were for npm audit and yarn audit.

[SHRoberts91]

I feel like 100 thumbs up should warrant some sort of response..

[arcanis]

Hey - I didn't see the upvotes, my bad.

I think it's something we would be interested in, but I'm currently short on time while I'm working on our next major release. If someone from the community is willing to put the work into adding support for it, I'd certainly be happy to review it! 🙂

[olingern]

@arcanis Maybe this should have an RFC? Could be a little involved.

From the npm v6.1.0-next.0 post:

NEW FEATURE: npm audit fix

This is the biggie with this release! npm audit fix does exactly what it says on the tin. It takes all the actionable reports from your npm audit and runs the installs automatically for you, so you don’t have to try to do all that mechanical work yourself!

Note that by default, npm audit fix will stick to semver-compatible changes, so you should be able to safely run it on most projects and carry on with your day without having to track down what breaking changes were included. If you want your (toplevel) dependencies to accept semver-major bumps as well, you can use npm audit fix --force and it’ll toss those in, as well. Since it’s running the npm installer under the hood, it also supports --production and --only=dev flags, as well as things like --dry-run, --json, and --package-lock-only, if you want more control over what it does.

[arcanis]

My full personal opinion on audit is that it's a good fix implemented at the wrong place. Because of this I'm not overly fond of having it in the default Yarn bundle. Ideally I'd prefer if it was implemented through a community plugin (and what a coincidence, the next major introduces plugins 😜).

The main reason I consider it a good thing to have in the v1 is that people expect it to have most of the npm features by default, so it makes sense to implement it the same way that they did, conceptually. In this situation we don't need a RFC, since the spec is pretty much "whatever already exists".

For the v2 I don't think it needs an RFC either because as I mentioned it'll likely be a community plugin - meaning that its maintainers will get to pick the logic they think suits the best their users, and if their users aren't happy with it they can just implement a different logic in a separate plugin.

Does that make sense?

[nickmccurdy]

It's a part of npm. To be an npm replacement, it should be a part of yarn.

[cdietschrun]

I'm surprised this is a discussion. This seems like required feature parity, if your tagline on your main site is:

"Install any package from npm and keep your package workflow the same."

[arcanis]

A PR would be more impactful than a discussion given that we already agree.

If someone from the community is willing to put the work into adding support for it, I'd certainly be happy to review it! 🙂

[cdietschrun]

It wasn't clear on reading this thread that there was agreement. I definitely cannot take this on at the moment.

[nazreen]

this is highly needed. I have 2 side project repos that I'll consider moving over to npm if this isn't addressed anytime soon. npm caught up by enforcing lock files. it's improved install speeds as well. yarn used to stand out clearly from npm as a replacement, but now it seems to need to catch up in at least one way, that happens to be rather crucial - aiding in keeping repos secure.

[Llanilek]

This is definitely a deal breaker for using yarn over npm. We have hundreds of projects which we use yarn, but the lack of audit fix is making it very difficult to maintain all those packages. It would be a sad day if we had to go back to npm.

[quisido]

Is there a rudimentary implementation of this for people to use in the meantime? Unfortunately, I don't believe we can just npm audit fix and then yarn again. Right now, it just feels like, "If you use yarn, you can't fix audits."

[goodevilgenius]

@CharlesStover If you're project is on GitHub, you can use Dependabot to automatically create PRs for you whenever dependencies need updating. It supports yarn.

[quisido]

Dependabot has managed to fix some but not all of my audits. Even in some repos with 3 needed fixes, Dependabot just fixes just one or two. I'm left scratching my head how to fix the last one. I've tried yarn upgrade and yarn upgrade package to no avail. I've received the advice to npm audit fix instead of upgrading, but alas it's a Yarn installation.

[karlhorky]

Maybe this isn't the right place for this discussion, but usually what I do is:

1. Search through the yarn.lock file for the dependency name, check what is depending on it and try to upgrade that.

2. If the package depending on it is also at the latest version, try looking at their repo online:

   • it may already have the fix but hasn't been published yet
   • there may be an open issue or PR for this
   • if all else fails, you can open an issue or PR for this
   
   

   In the meantime, if it's safe to upgrade the problematic dependency (if it still works with the latest version of the package depending on it), you can use a Yarn resolution like here.

[arcanis]

(this comment was in response to another comment that its owner deleted)

If someone from the community is willing to put the work into adding support for it, I'd certainly be happy to review it! 🙂

Now can you all stop with the obnoxious passive aggressiveness? You're not as subtil as you think, and I don't care as much as you think either.

[arcanis]

(Answering a comment its author deleted)

[...] after seeing the reaction into a simple comment to bump an issue (which I'm not being aggressive, just remarking that is a bummer to have to go back again into npm) I can't see how we can cooperate for a PR to happen

Take it from my perspective. The yarn audit command has been hyped by a company to tie your projects to their services. Its HTTP API is npm-specific for who-knows-what-reason. The security it provides is extremely limited (it's an after-the-fact bandaid; you will just know you have already been compromised, it won't help you prevent it, and you won't even know about it until after you redeploy your project), generates a lot of noise, and the service behind it is regularly flaky. In this context, I hope you can understand I believe to have better ways to spend my time - including on Yarn itself.

Yarn is a community project. Everything so far got done because people decided that they cared enough about a feature to implement them. Our work as maintainers is to help them figure out how to do it in an idiomatic way. Not to implement features for you. Sometimes (relatively often) we happen to believe in a feature enough to spend our own time implementing it. This is not one of these cases, at least not for me.

I think we all said everything we had in mind, I'm going to lock this issue for now. Again, I'd be happy to spend some of my time helping you land it into Yarn; I just won't do it for you.