Trailing slash breaks workspace features when yarn run inside workspace folder

[j-maas]

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

Bug.

What is the current behavior?
When the workspaces definition contains a trailing slash, running e. g. yarn workspaces info in the root works just as expected. But when you cd into the workspace folder and run yarn workspaces info, it fails because it cannot detect that that folder is a workspace.

If the current behavior is a bug, please provide the steps to reproduce.

1. Create a new project directory.
2. Create a subdirectory called package.
3. yarn init inside package/.
4. yarn init in the root.
5. Add package/ (with trailing slash) as a workspace to the root package.json.

   ...
   "workspaces": {
     "packages": [
       "package/"
     ],
   },
   ...
   

6. Run yarn workspaces info in the root. => Outputs workspace list correctly.
7. Run yarn workspaces info in package/. => Fails with

   yarn workspaces v1.6.0
   error Cannot find the root of your workspace - are you sure you're currently in a workspace?
   info Visit https://yarnpkg.com/en/docs/cli/workspaces for documentation about this command.
   

What is the expected behavior?
Running yarn workspaces info should output the workspaces when run both inside root and package/.

If this behavior is intended, the documentation could reflect the reason why.

Please mention your node.js, yarn and operating system version.
Node v8.11.1
Yarn v1.6.0
Ubuntu 16.04 LTS

[arcanis]

Nope, you're right, this is a bug. Do you want to give it a shot at figuring out what happens and fixing it?

…

On Mon, May 14, 2018, 9:26 AM heupr[bot] ***@***.***> wrote: Assigned #5816 <#5816> to @arcanis <https://github.com/arcanis>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#5816 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_Wa18OSpfW6rTG_t623qZvuqVQko3xks5tyT-ngaJpZM4T9WzR> .

[j-maas]

@arcanis I'm not sure if I'll have time, but in principle I'd like to try.

I'll write a new comment before I start, so that you know whether I'm working on this. Until then, if anyone would like to tackle this, go ahead.

[j-maas]

I've started looking into it and I assume the root cause lies in micromatch or the arguments passed to it.

I will continue diggin for a bit.

[j-maas]

This behaviour is reportedly supported in a newer version of micromatch.
The newest version is 3.1.10, whereas yarn is dependent on 2.3.11.
(It doesn't work in the newest version.)

I'm not sure how to add a test case for this bug. If you have any suggestions, I could try.

[j-maas]

This is considered intended behavior micromatch. It thus should be handled in the call to the function.

[07Gond]

Hi, @arcanis & @BYK is this issue still relevant?

[thomassuckow]

Just ran into this in v1.10.1.

Edit: This explains why yarn add would create a yarn.lock in some workspaces but not others.