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] notifications@github.com wrote:

Assigned #5816 https://github.com/yarnpkg/yarn/issues/5816 to @arcanis https://github.com/arcanis.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/yarnpkg/yarn/issues/5816#event-1624209611, 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.

[joefiorini]

I also just ran into this issue in yarn v1.15.2. Crazy.

[forivall]

I ran into what is probably the same issue, where instead of a trailing /, it was caused by a preceding ./

For example:

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

[simkessy]

Currently having this issue with this config:

    "workspaces": [
        "libs/common/client/",
        "services/app/client/"
    ]

At the root, I can find the packages. But at the package level, it doesn't recognize it's part of a workspace. How do I fix this?

If I go to the package and add a dependency, it will create it in the packages node_modules instead of root.

[forivall]

@simkessy for now, the workaround is to change that to

    "workspaces": [
        "libs/common/client",
        "services/app/client"
    ]

[simkessy]

Wow, that was simple. This should be documented somewhere, wasted a lot of hours :(

Thanks @forivall !