Allow custom yarn mutex from lerna.json config

[ChristopheVandePoel]

** hold on, getting this explanation in order :)
This small change adds the possibility for the user to add his own mutex setting.

Description

The current rc of lerna defaults lerna to the use of --mutex network:424242.

With this commit the user can add a 'mutex' setting to lerna.json to choose for himself what type of setting he prefers.

{
  "lerna": "2.0.0-rc.4",
  "packages": [
    "packages/*"
  ],
  "mutex": "file:/path/to/file",
  "npmClient": "yarn",
  "version": "independent"
}

A limitation with this approach seems to be that the mutex has to be called with a path that is located outside the main packages, if not, the lock is created in de package dir itself and so for every package, which off course defeats the purpose. The path either needs to be absolute or located in the parent-packages directory (or higher).

Motivation and Context

For some people (including me) working with the default network mutex does not work on every environment after a yarn cache clean && lerna clean.

Ran into trouble when trying to use it on WSL and it seems that there are some docker-users that are also affected by this problem. It's not entirely clear why these environments ignore the network mutex, but they do. WSL does not seem to ignore it if you change the mutex to use a file in stead. This commit gives the user the possibility to do so.

Issue reference:
#789
and I guess this one:
yarnpkg/yarn#3327

How Has This Been Tested?

Built with the changes and if a file is set, the issue seems resolved. Ran both normal and integration tests without the issue occurring. On that note, If I run the integration tests on WSL with the current rc.4, they do not pass.

Further than that, this has not been tested in-depth with a lengthy use-case. It seems that the change I made is pretty much confined to the bootstrap command, although I cannot be entirely sure if nothing else is affected here.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[evocateur]

Please fill out the relevant template parts and add a test, thanks!

[ChristopheVandePoel]

Sorry, I hit ctrl+enter accidentally.

I'll add a test asap

[ChristopheVandePoel]

I added a test, but did not change the integration test, since there seems to be an issue with yarn supporting file:// as in the existing comment block there.

[evocateur]

I've kicked a new AppVeyor build, the failure looks oddly unrelated.

It's okay to omit the integration test for now, the unit test is plenty for this sort of thing.

[evocateur]

Not that it changes the fact you've experienced this issue with the network mutex, but the mutex creation currently only prefers 42424, which get-port attempts to provide, falling back to a random port.

[evocateur]

Would you mind adding a blurb about the mutex config in lerna.json in the --npm-client block of the README? I would do it myself, but I can't make edits to your clone's master branch. Thanks!

[ChristopheVandePoel]

I'll do that as soon as I can.

FTR, I ran get-port with 42424 straight in node and it gave me back the port without issue or error.

IIRC the error during install also showed me that yarn install --mutex network:42424 failed, and that command has to come after get-port has found an open port.

I have some more ideas how I can test this and will try to do them later today. But what I seem to see here, is that yarn (not lerna) ignores the mutex when it is set as a network in some cases.

[jwb]

Without looking at the code for this, I wonder if the problem results from get-port allocating a random port not properly passing that port to descendants.

[evocateur]

No, get-port returns a Promise, which when resolved calls BootstrapCommand's initialize callback appropriately. I agree that it must be wonkiness on yarn's side. Just need some documentation of the flag and we can get this merged.

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.