Lerna does not find packages in non-default locations as of rc.4 - rc.3 works fine

[remotezygote]

Expected Behavior

The expected behavior is for lerna to find/manage packages as it did before rc.4. Previous output of lerna ls:

Lerna v2.0.0-rc.3
Independent Versioning Mode
@<redacted>/<redacted>         v1.0.41 
node-readme                    v0.1.10 
@<redacted>/<redacted>         v1.0.41 
@<redacted>/<redacted>         v1.1.6  
@<redacted>/<redacted>         v1.0.55 
@<redacted>/<redacted>         v1.0.60 
@<redacted>/<redacted>         v0.0.12 
@<redacted>/<redacted>         v1.0.18 
@<redacted>/<redacted>         v1.0.25 
@<redacted>/<redacted>         v1.0.9  
@<redacted>/<redacted>         v1.0.8  
@<redacted>/<redacted>         v1.0.19 

Current Behavior

Current output of lerna ls:

lerna info version 2.0.0-rc.4
lerna info versioning independent
@<redacted>/<redacted> v1.0.41 

Steps to Reproduce (for bugs)

1. Create a lerna-managed repo.
2. Put your packages in a folder other than the default packages folder.
3. Run lerna ls

lerna.json

{
  "lerna": "2.0.0-beta.38",
  "packages": [
    "./",
    "packages/node_modules/*",
    "packages/node_modules/@opallabs/*"
  ],
  "version": "independent"
}

Context

This makes all commands work only on the "main" package that it still finds. It should perform all commands against the full list of packages.

Your Environment

As you can see from the lerna.json file above, I have my packages inside a node_modules directory inside the packages directory. This was something suggested by a posting from the PouchDB team, and works well. Worked well, until rc.4, I should say :) .

Executable	Version
lerna --version	2.0.0-rc.4
npm --version	4.5.0
node --version	v7.8.0

OS	Version
NAME	VERSION
macOS Sierra	10.12.3

[evocateur]

It's not exactly accurate to say "non-default packages locations are broken", because clearly non-default packages locations that don't contain the string node_modules are just fine (I use it literally every day, so I'd know).

If you're using the "alle" approach referenced in this blog post and spitballed here, why bother with lerna still?

I suppose it's simple enough to check if any of the packages members has the literal string node_modules in it, and omit the ignore: ["**/node_modules**"] glob config. Still mystified why this is considered a good idea, tbh.

[remotezygote]

Was it a conscious decision to ignore packages under node_modules directories in the latest RC? I saw nothing about that in any release notes. I'm just pointing out that something that worked perfectly in rc.3 does not work at all in rc.4. Regardless of the words used, I thought it important to point out a workflow that worked great before the latest RC, and works not at all in the latest RC.

[remotezygote]

FWIW, the reason we've ended up on a hybrid approach is because lerna bootstrap is so unbelievably slow with dependencies spread all over. Lerna is still a great tool to run commands in all packages and publish new versions, even if you don't use the bootstrapping logic.

[evocateur]

Hoisting solves the vast majority of those slow bootstrapping cases.

…

On Apr 28, 2017, at 17:25, John Bragg ***@***.***> wrote: FWIW, the reason we've ended up on a hybrid approach is because lerna bootstrap is so unbelievably slow with dependencies spread all over. Lerna is still a great tool to run commands in all packages and publish new versions, even if you don't use the bootstrapping logic. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[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.