Renovate: Support yarn.lock maintenance

[rarkins]

Current yarn support means that we update yarn.lock whenever we update package.json, but otherwise leave it alone.

An additional feature could be to periodically "maintain" the yarn.lock file by regenerating it and committing it if it's updated.

[hutson]

This would seem like the next logical step on the way to more granular updates of the lock file.

[rarkins]

Every time renovate runs on a package file, it should:

• Check if yarn.lock exists
• Stop yarn logic if none exists
• Generate new yarn.lock using package.json
• Compare old and new yarn lock files
• Create/update pull request if yarn lock files differ

[ghost]

Is yarn.lock an absolutely required feature? We don't use yarn in our proyects, I don't see why we should keep a yarn.lock versioned for renovate. Can we ignore it with .gitignore or that would break renovate from working?

[rarkins]

It should be entirely optional and only edit a yarn.lock file if one already exists. Please file a bug if you see any other behaviour in the latest version!

[hutson]

One of renovate's strengths, in my opinion, is that API-only is a core feature of the tool.

It's not possible since running yarn install or yarn upgrade needs access to a file system. I'm keeping an eye on yarnpkg/yarn#2755 as it will reduce the time needed to run the yarn operations (no writing packages to disk).

[rarkins]

The ideal would be that yarn can be invoked via an API call and requiring no filesystem at all, e.g. pass it a package.json and get back a yarn.lock file contents.

Next best would be anything via CLI that avoids a full install/reinstall of all node modules, which perhaps the issue you linked to helps resolve.