Yarn workspaces

[rarkins]

• set experimental workspaces flag true
  • looks like won't be needed in next yarn release
• always generate root yarn.lock even if it's package.json hasn't changed
• implicitly detect which packages should be ignored and not updated by Renovate
  • do directory names always match npm names? I don't think so because npm names might be scoped

[hutson]

It has been the intention of Facebook to merge Lerna into Yarn - yarnpkg/yarn#946 (comment)

As noted by one of the Yarn core team members, Yarn Workspaces is the native support for Lerna like workflows - yarnpkg/yarn#946 (comment)

So, in short, Yarn Workspaces is likely to be the future for monorepos (at least for those currently using lerna).

[rarkins]

Blog post in progress here: https://github.com/yarnpkg/website/pull/580/files (https://deploy-preview-580--yarnpkg.netlify.com/blog/2017/07/26/introducing-workspaces/)

Some notes for now:

• yarn 0.28
• Needs flag in .yarnrc
• Can integrate with lerna
• Generally it will hoist all node_modules to the root but will keep them in subdirs if there are version conflicts
• Only one yarn.lock created (at root)
• yarn install can be run from any package.json location but the yarn.lock is updated only in the root

[rarkins]

This means we need to emulate the same nested directory structure of package.json files locally before running yarn install to generate the yarn.lock. It sounds like yarn install can perhaps be run from any of the subdirectories or the root directory, but I'm thinking it's easiest if we run it from root each time regardless of which file(s) have changed.

[rarkins]

We also should incorpoate lerna detection and yarn detection. With lerna we simply look at the packages glob to find all package names and then auto-ignore those (i.e. don't attempt to renovate them). I found for apollographql/apollo-server though that there was an internal/unpublished yet versioned test package that the others used. In package.json it "looked" like a normal npmjs image but I guess lerna uses some magic to know that it should be linked internally instead of downloaded from npm. Unless we incorporate that "magic" - or the lerna/workspaces integration does away with it for something more explicit - then generation of any yarn.lock will fail.

[denkristoffer]

We've been using Yarn workspaces since before adding renovate to our repo. A few issues I've noticed, although I'm unsure if they're related to workspaces or a problem with the configuration :)

• The yarn.lock in the root of the repo is not being updated.
• "prCreation": "not-pending" didn't seem to work, as PRs were created before unpublish-safe was green.
• Setting "semanticCommits": true doesn't seem to change anything.

Using the following config:

  "renovate": {
    "pinVersions": true,
    "semanticCommits": true,
    "assignees": ["denkristoffer"],
    "prCreation": "not-pending",
    "automerge": "minor"
  }

Is there anything in particular I can help test?

[rarkins]

@denkristoffer thanks for the feedback.

The yarn.lock in the root of the repo is not being updated

Does this root package.json have any dependencies of its own that you expect to be updated? Right now Renovate isn't aware that the yarn.lock in root is for all package.json files so would only update it if the root package.json is updated.

"prCreation": "not-pending" didn't seem to work, as PRs were created before unpublish-safe was green.

unpublish-safe was perhaps a bit of a mistake by me. I enabled it by default but found most users wanted to disable it, so I changed the default back to disabled. You should only see it now if you manually enable it. Sorry for any confusion - from now on I will be adopting a "law of least surprises" when it comes to new feature enablement.

• Setting "semanticCommits": true doesn't seem to change anything.

Semantic commits/prefixes should now be detected every run, based on the most recent commit history in the repo. So if you're already using semantic commits then so will Renovate, however you can manually enable or disable (override) this by setting to true or false. What are you seeing?

Your config looks fine btw - although pinVersions=true is the default behaviour so not necessary to configure manually.

[denkristoffer]

Does this root package.json have any dependencies of its own that you expect to be updated?

Yes, it has a few devDependencies like lint-staged and prettier but they rarely get updated. So far I've just decided to run yarn from the root manually.

unpublish-safe was perhaps a bit of a mistake by me. I enabled it by default but found most users wanted to disable it, so I changed the default back to disabled. You should only see it now if you manually enable it.

Even when it was enabled, it didn't seem to respect the "prCreation": "not-pending" setting, it would create the PRs before the 24 hours had passed. It was my impression that it was supposed to wait before creating the PR?

if you're already using semantic commits then so will Renovate, however you can manually enable or disable (override) this by setting to true or false. What are you seeing?

We haven't actually switched to using semantic commits ourselves yet, I was hoping to take the first step by using it with renovate 🙂 The latest PR from renovate is called "Update dependency @data-ui/histogram to v0.0.6" – that's from 12 hours ago even though I added "semanticCommits": true more than two weeks ago.