Skip to content

child-concurrency is parsed as a string instead of number when shared-workspace-lockfile=false #5075

Closed
@ItamarGronich

Description

pnpm version:

7.5.2

Code to reproduce the issue:

use node 17.9.1 and pnpm 7.5.2
https://github.com/ItamarGronich/pnpm-bug-child-concurrency

Expected behavior:

child-concurrency is parsed as number and not a string

Actual behavior:

child-concurrency is parsed as a string

Additional information:

Using share-workspace-lockfile=false and child-concurrency=10 doesn't work.
pnpm seems to parse it as a string instead of a number and throws:

ERROR  Expected `concurrency` to be a number from 1 and up

TypeError: Expected `concurrency` to be a number from 1 and up
    at pLimit (/Users/itamar.gronich/.nvm/versions/node/v17.9.1/lib/node_modules/pnpm/dist/pnpm.cjs:51274:15)
    at exports2.default (/Users/itamar.gronich/.nvm/versions/node/v17.9.1/lib/node_modules/pnpm/dist/pnpm.cjs:108848:24)
    at _rebuild (/Users/itamar.gronich/.nvm/versions/node/v17.9.1/lib/node_modules/pnpm/dist/pnpm.cjs:109882:38)
    at rebuildProjects (/Users/itamar.gronich/.nvm/versions/node/v17.9.1/lib/node_modules/pnpm/dist/pnpm.cjs:109766:41)
    at async /Users/itamar.gronich/.nvm/versions/node/v17.9.1/lib/node_modules/pnpm/dist/pnpm.cjs:110449:13

I'm actually not 100% sure about what child-concurrency does precisely.
I thought i can make pnpm install faster in a split lockfile scenario because it will just run on more packages concurrently. where it by default installs only 4 packages concurrently and then moves on to the next.

I tried some different configs - workspace-concurrency works as expected however.

I did some debugging and i think (i think) that it maybe comes from here and possibly from here too.

  • node -v prints: 17.9.1
  • macOS

Side track warning:
I actually discovered something i think is another bug:
when you remove the child-concurrency flag you can see that the first 4 packages are indeed installed concurrently.
However the next packages don't. pnpm basically waits for all 4 packages to finish, only then does it start the next packages but even then it does them one by one.
I would have expected that as soon as one package finishes, another will take it's place so there's always 4 running.
Let me know if you want me to open another bug for this.
Side tracking done.

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions