lerna create <loc> misrecords subpackage location

[mikestopcontinues]

Given:

{
  "version": "0.0.0",
  "npmClient": "npm",
  "packages": [
    "apps/*",
    "libs/*"
  ]
}

When I run lerna create pkg libs/pkg, it creates the package at apps/pkg, but still points to an erroneous location. This caused folke/vscode-monorepo-workspace#34.

I later realized I could achieve the desired effect with lerna create pkg libs, though this prevents you from easily creating a package whose name and directory are different.

Additionally, I didn't receive an error saying the location was invalid, nor a warning indicating the package was put in the default location.

Expected Behavior

I would prefer if I run lerna create @ns/long-pack-name libs/short for the package to be placed at libs/short with name @ns/long-pack-name. And if libs/short didn't match any package globs, I would prefer an error message.

If this doesn't work for you, I would at least prefer an error to creating the package in a location I didn't select.

Current Behavior

Currently, no errors are issued, the package is created in the wrong location, and the package isn't correctly recorded, wherever that data is stored.

Context

This lerna.json is simplified from my setup—a multi-app deployment. I'm subdividing a rather big project into multiple subdirectories to streamline an infra-as-code ci/cd pipeline. I have discovered work arounds for what I need to do (lots of lerna bootstrap), but I really just want a quick way to initialize new packages.

Your Environment

Executable	Version
lerna --version	3.20.2
npm --version	6.14.3
yarn --version	no
node --version	13.10.1

OS	Version
NAME	VERSION
macOS Sierra	10.15.3

[MagicalBridge]

I also had the same problem

[napster99]

run into the same problem

[richardantao]

It looks like the output folder will simply be the first blob in the packages array in your lerna.json.

At first, my lerna.json was simply:

{
  "packages": [
    "packages/*"
  ],
  "version": "0.0.0"
}

And packages would only get placed directly under the packages folder, regardless of what path I passed to in [loc] lerna create <name> [loc].

Then, when my lerna.json was:

{
  "packages": [
    "packages/apps/*",
    "packages/libs/*"
  ],
  "version": "0.0.0"
}

Packages would only be placed in the packages/apps folder, even when I tried to create with lerna create <package-name> ./packages/libs/<package-name>.

[atomictangerine]

It may be worth noting that if you're using useWorkspaces: true on your lerna.json, it will ignore whatever you have under packages: [] and instead only use the order you've specified in your root package.json workspaces: [].

[Vivek-Yarra]

i looked at the command code. it's here

lerna/commands/create/index.js

Line 59 in 1c39987

this.project.packageParentDirs.find((pd) => pd.indexOf(pkgLocation) > -1) ||

this logic fails in lot of cases,

this explains the reason why we are facing the issue.
so not a clean way but the following works for me now. (all i am trying to do is make sure index of doesn't return -1)

{
"useWorkspaces": false,
  "packages": [
    "packages/apps/*",
    "packages/libs/*"
  ],
  "version": "0.0.0"
}

this works because indexof logic is satisfied by apps, libs values for loc variable

lerna create My_New_App apps
lerna create My_New_Lib libs

this works because / in the packages is replaced by \ and when you use packages/apps it is compared against packages\apps from the lerna.json file and it fails. but when you use the value packages\apps it will work.

lerna create My_New_App_1 packages\apps
lerna create My_New_Lib_2 packages\libs

so you can use any of the above logics, removing indexof and using an exact string match (after removing wild cards and ignoring OS specific file Seperator ) would be a better implementation.

Thanks

[JamesHenry]

Thanks for reporting this folks! We will gladly review PRs to improve this behaviour, I agree it seems to currently be unintuitive or broken in certain cases.

Additionally, I have opened an issue to track improvements to customizing lerna create more broadly here: #3444

[JamesHenry]

Thanks to @fahslaj this was addressed in #3478