yarnpkg / berry

📦🐈 Active development trunk for Yarn ⚒
https://yarnpkg.com
BSD 2-Clause "Simplified" License
7.35k stars 1.1k forks source link

[Bug?]: Process hangs with parallel-prettier #4354

Open AllanZhengYP opened 2 years ago

AllanZhengYP commented 2 years ago

Self-service

Describe the bug

We use the dependency @mixer/parallel-prettier to prettify our huge codebase in parallel. However, formatting process hangs if the dependency co-exists with some other dependencies(i.e. concurrently). I looked into the source code, it looks normal, other than it uses cluster module.

To reproduce


Playground

await packageJsonAndInstall({
    devDependencies: {
        "@mixer/parallel-prettier": "^2.0.1",
        "concurrently": "7.0.0" // <==== this is causing the process to hang. Removing this the app runs properly again.
    },
    scripts: {
        "format": "pprettier --write ./package.json"
    },
    packageManager: "yarn@3.2.0",
});

expect(await yarn('run', 'format')).toBeDefined();

Environment

System:
    OS: macOS 12.2.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 14.19.1 - /private/var/folders/28/yhtzwdv94rg8cf93ncdjc02h0000gr/T/xfs-2f0d5096/node
    Yarn: 3.2.0 - /private/var/folders/28/yhtzwdv94rg8cf93ncdjc02h0000gr/T/xfs-2f0d5096/yarn
    npm: 6.14.16 - ~/.nvm/versions/node/v14.19.1/bin/npm

Additional context

I did a search in our other dependencies, it seems like many other dependencies will cause the same issue like concurrently:

    "@commitlint/cli": "^11.0.0",
    "@typescript-eslint/eslint-plugin": "5.15.0",
    "@typescript-eslint/parser": "5.15.0"
    "concurrently": "7.0.0",
    "eslint": "8.11.0",
    "lerna": "3.22.1",
    "lint-staged": "^10.0.1",
    "mocha": "^8.0.1",
    "ts-jest": "27.1.4"
    "strip-comments": "2.0.1"
    "esprint": "3.3.0"
    "jest": "27.4.5",
    "karma": "^5.1.0",
    "karma-typescript": "5.5.3"

I don't think they share a lot commonalities.

merceyz commented 2 years ago

I'm guessing this is the same issue as https://github.com/yarnpkg/berry/issues/4157, can you test with Node.js v16.14 or v17.4?

AllanZhengYP commented 2 years ago

@merceyz Thank you for the response. I tested on v16.14 but still got no luck:

  System:
    OS: macOS 12.2.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 16.14.2 - /private/var/folders/28/yhtzwdv94rg8cf93ncdjc02h0000gr/T/xfs-79ab10bc/node
    Yarn: 3.2.0 - /private/var/folders/28/yhtzwdv94rg8cf93ncdjc02h0000gr/T/xfs-79ab10bc/yarn
    npm: 8.5.0 - ~/.nvm/versions/node/v16.14.2/bin/npm
AllanZhengYP commented 2 years ago

@merceyz The issue still exists, can you take another look?

yarnbot commented 2 years ago

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

RDIL commented 2 years ago

I attempted to reproduce the issue, but didn't have any luck. Are you able to provide a repository that allows for a minimal reproduction of the behavior?

merceyz commented 2 years ago

I can reproduce with the following commands

docker run --rm -it node:16.15.0 bash
mkdir foo
cd foo
corepack enable
corepack prepare yarn@3.2.1 --activate
yarn init
yarn add @mixer/parallel-prettier@2.0.1 concurrently@7.0.0
yarn pprettier --write ./package.json
RDIL commented 2 years ago

Interesting discovery... after running yarn config set pnpEnableEsmLoader false, it starts working. I wonder if this is some type of dynamic import type issue, or the issue Node.js had for a while with child_processes not being ready when loaded under ESM.