Berry: [Bug] Bugs blocking usage of Berry

[cpojer]

Describe the bug

I am trying to use Berry on existing projects. I'm running into multiple blockers, and some UX issues. I tried to look at using Berry with a beginner-mindset, blending out any sort of knowledge I may have about existing projects or dependency management. This bug report was filed to help identify a few ways in which Berry could help beginners successfully migrate to Berry.

• UX: After running Berry it reported that it "Failed with errors". It was unclear what to do next, and whether it was a legitimate error or not. I had to open a log file in a temporary folder to see that a module could not be resolved (triggered through running postinstall after yarn?). Since this is caused through my usage of Berry, and wouldn't happen with Yarn 1 or npm, I believe it could be made clearer what the next steps should be.
• UX: On first-run, Berry spams my terminal with one message per package that needs to be downloaded. For a large project, that can be tens of pages of terminal windows.
• Bug: After trying to run yarn jest to run tests, Berry couldn't resolve modules across the workspace and failed with an unhandled promise rejection. I was left in a state where I'm unable to know how to continue.
• Bug: Trying to run yarn policies set-version <anything> when Berry is active resulted in an error Couldn't find a script named "policies".. I am unclear how to revert to Yarn 1.
• Perf: the link step for repeated invocations of Berry takes multiple seconds, as opposed to Yarn 1 which is immediate.
• Behavior change: It appears Berry does either not print the output of postinstall steps or doesn't run them on repeated invocations (Tested on the Metro repo which builds all files on every invocation of Yarn). Is this expected?
• UX: Berry does not print anything to the terminal when running a command, which feels like something got stuck when running a slow command (like eslint for example).
• UX: I tried to run yarn policies set-version berry in a project with an older version of Yarn (1.17). The policies command was not found, but it was unclear that this was a command only added recently. I don't know what could be done on existing versions but at least documentation could be clearer about updating Yarn 1 to the latest
• UX (subjective): Every line printed by Berry has a vertical bar (|) which looks visually jarring at times.
• UX (subjective): Every line contains > YN0 which feels repetitive.

Feel free to split these out into separate issues. My intent is to document the complete flow I went through and the issues that came up. I also tried Yarn on another smaller and older project. Because many of the dependencies were using versions that were old I could not get Berry to work. It may help to point out in the migration guide that all dependencies should be updated to the latest versions before changing dependency managers. It would be amazing if Berry could fail on install and tell me which versions of packages are known to work with Berry (ie. if I'm using an old version of resolve, Berry could automatically tell me which version is compatible).

To Reproduce

git clone [email protected]:facebook/jest.git
cd jest
yarn policies set-version berry
yarn

Screenshots

Environment if relevant (please complete the following information):

• OS: macOS
• Node version: v12.8.0
• Yarn version: berry

[cpojer]

For full context, these are the four repos I tried:

• https://github.com/facebook/jest (failed)
• https://github.com/facebook/metro (worked!)
• https://github.com/cpojer/js-codemod (failed, outdated dependencies not supported via Berry)
• https://github.com/facebook/react-native-website (fails on yarn start with Failed to start Docusaurus server: Error: EROFS: read-only filesystem, open '/node_modules/docusaurus/lib/core/metadata.js' – unclear how to proceed)

[larixer]

https://github.com/facebook/react-native-website (fails on yarn start with Failed to start Docusaurus server: Error: EROFS: read-only filesystem, open '/node_modules/docusaurus/lib/core/metadata.js' – unclear how to proceed)

yarn unplug docusaurus
but error message should be better...

[arcanis]

Hey, thanks for that 🙂

Bug: Trying to run yarn policies set-version when Berry is active resulted in an error Couldn't find a script named "policies".. I am unclear how to revert to Yarn 1.

Related to #472

Perf: the link step for repeated invocations of Berry takes multiple seconds, as opposed to Yarn 1 which is immediate.

1.x was "cheating" by just not running at all if the .yarn-metadata had an older mtime than the package.json and yarn.lock files. It's a fine approach, but here we follow a slightly different one where we want to run the full code path and make it fast (not the source, but this tweets sums it up perfectly: https://twitter.com/jordwalke/status/959018527091904512).

I find this approach important because the bypass had side effects that made the execution slightly unpredictable from the perspective of tooling (cf next point). For example as another data point, running yarn install here will always ensure that your cache is sound instead of just passing if one mtime happens to be the right one.

Behavior change: It appears Berry does either not print the output of postinstall steps or doesn't run them on repeated invocations (Tested on the Metro repo which builds all files on every invocation of Yarn). Is this expected?

The 2.x will not print the logs for successful builds (just like 1.x), but it will also not run the postinstall scripts unless the dependency tree changed. The 1.x tried to have a similar behaviour (for example the bypass previously mentioned caused the postinstall scripts to not be run on every install) but was fairly buggy and sometimes unpredictable in this aspect.

UX: I tried to run yarn policies set-version berry in a project with an older version of Yarn (1.17). The policies command was not found, but it was unclear that this was a command only added recently. I don't know what could be done on existing versions but at least documentation could be clearer about updating Yarn 1 to the latest

Yep, we should mention upgrading 1.x before installing 2.x 👍

It would be amazing if Berry could fail on install and tell me which versions of packages are known to work with Berry (ie. if I'm using an old version of resolve, Berry could automatically tell me which version is compatible).

That's something we consider. The plugin-compat is here for this kind of purpose (for example it automatically adds the missing package extensions we're aware of), and we'll keep improving it based on similar feedback.

UX: On first-run, Berry spams my terminal with one message per package that needs to be downloaded. For a large project, that can be tens of pages of terminal windows.

It won't work for first-time users, but for regular use we'll implement #816 which will make it possible to filter out the messages you don't want to see. By default I find the full list valuable though - the typical progress bars used to make it difficult to know what was causing hangs, especially when people shared screenshots.

(fails on yarn start with Failed to start Docusaurus server: Error: EROFS: read-only filesystem, open '/node_modules/docusaurus/lib/core/metadata.js' – unclear how to proceed)

We try to throw the regular filesystem errors as much as possible when working with zip archives, hence the EROFS (Error Read-Only FS). I'll add it to the troubleshooting though (basically it means that Docusaurus is writing within its own package folder instead of something like /node_modules/.cache/docusaurus).

[merceyz]

We try to throw the regular filesystem errors as much as possible when working with zip archives, hence the EROFS (Error Read-Only FS). I'll add it to the troubleshooting though (basically it means that Docusaurus is writing within its own package folder instead of something like /node_modules/.cache/docusaurus).

Tracked it down to this place in the source https://github.com/facebook/docusaurus/blob/166816af40bd14ec851472bc99921815962f72f1/packages/docusaurus-1.x/lib/server/readMetadata.js#L352-L359
cc @yangshun @endiliey

[yangshun]

it means that Docusaurus is writing within its own package folder instead of something like /node_modules/.cache/docusaurus

We're aware of that bad practice (which predates our involvement in the project). We made a conscious effort to avoid doing that in v2. Would the problem be solved if we wrote the file outside of the package? If so we could take a stab at it. cc @lex111

[merceyz]

Yes, saving it in the node_modules/.cache folder would solve that issue

[arcanis]

We were thinking with @gaetanmaisse that maybe the Yarn org could provide an helper package to store package artifacts. Maybe that would be good opportunity to mutualize efforts?

[haggholm]

• Perf: the link step for repeated invocations of Berry takes multiple seconds, as opposed to Yarn 1 which is immediate.

I have a large project with a number of workspace that takes, at last check, 165s with Yarn 1.21.1. With Berry, it took _over 14 minutes_—five times as long—nearly all of it spent in the link step (the resolution, by contrast, was virtually instantaneous). This was both on the first install and on subsequent invocations.

[arcanis]

@haggholm can you open a separate issue with as much repro steps and information as you can (whether it was PnP or node_modules, inside Docker or similar environments, filesystem type, dependency list & lockfile, etc)?

14 minutes is well outside of what we would expect, so let's investigate that separately.

[haggholm]

@haggholm can you open a separate issue with as much repro steps and information as you can (whether it was PnP or node_modules, inside Docker or similar environments, filesystem type, dependency list & lockfile, etc)?

14 minutes is _well_ outside of what we would expect, so let's investigate that separately.

@arcanis I wish I could, but right now I don’t have any useful information to share. It’s PnP, not in Docker, but—the repository is internal/closed source with a lot of internal dependencies, which I cannot share, and I get no useful logs (it stays stuck at “Link step” for, a record now, as much as 43 minutes!!!), with no details, nothing in the error log except two lines about a package that failed, no output even with DEBUG='*' CI=1 yarn --inline-builds (still just quietly sits at “Link step” for ages).

If you can think of a way I could provide useful information while unable to share the repository—some way of getting more logs, perhaps—I’ll gladly open a new issue.

[TomCaserta]

Getting the same thing @haggholm with a workspace with 19 packages in total, resolve and fetch is over in 4 seconds, link step is 39 minutes without any logging output apart from X must be rebuilt because its dependency tree changed.

Going to see if I can get it to provide more debugging information in order to actually see whats wrong. I have noticed it's getting slower and slower each time I run yarn, not sure if thats a coincidence though.

Edit: found some things listing here just in case I forget but for example on one of the runs https://github.com/yarnpkg/berry/blob/8b8483bc95f3e39e597c77087e61dc2c2fc21447/packages/yarnpkg-core/sources/Project.ts#L1141 this took 21 minutes to run while usually it'd have returned in 0.006ms. Will create a ticket when I find the reason.