Honestly, I'm not sure this is a command we really want in the core ...

• On one hand, it would certainly be useful in some cases. For example, Yarn's deploy process is creating multiple times the same archive, and being able to build them once in all the steps and reuse it rather than rebuilding would improve that quite a bit.

• On the other hand, dissociating the packing from the publishing leads to annoying ambiguities. For instance, we currently look at publishConfig.registry to know where to publish the package. Where should we look? The one inside the packed tarball, or the one inside the project?

So I'm still on the fence about adding this ...

We currently use rename, so the temporary directory can't be moved if on a different drive than where we're installing the versions. We should change the temporary directory to instead be next to the final location, or at least within the ~/.node folder (this way we're sure they're on the same drive as the destination).

This thread is meant to discuss the init workflow. For example, what happens when running yarn init or npm init? Under the current model those commands will fail, because pmm is implemented in such a way that the package.json is created before spawning the process, which will then detect the preexisting manifest and refuse to update it.

My opinion about this is that the current behaviour isn't a problem. Justifications:

• Under the current model, npm is unmodified, so users would be able to use npm install -g or npx regardless of the package manager for the current project. This reason alone makes this problem non-blocking, although it's an interesting discussion nonetheless.

• Using pnpx on a Yarn project (or even npx, even if not applicable because of the first point) may be dangerous. For example, we are looking to make yarn dlx (the Yarn equivalent) persist some parts of the local configuration (for example custom registries). Using a different package manager for the "x" command would lead to installs being made based on the incorrect configuration, so packages would be installed from the wrong registry.

• The initial point that "projects decide which package managers they are meant to be used with" doesn't apply here, because global commands aren't cloning them - they are installing them, as any other command. For this reason, requiring to use yarn dlx on Yarn projects (rather than allowing pnpx) won't have negative effects.

This thread aims to discuss the "global packages" scenario. For example, the pmm version of pnpx --version currently prompts for project initialization if run within a Yarn project.

Good idea 👍

That said, the std namespace is more from a public API interface (for example adding a new function, or a new parameter, or changing a return type) - I'm not sure there's really a need to bump it here 🤔

Perfect, thanks!

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

Travis CI is calling yarn --frozen-lockfile by default and that behaviour cannot be overriden (as far as I know). When bumping from Yarn to Berry it make builds crash at start-up on Travis.

This PR shows that Travis can be detected by using the check !!process.env.TRAVIS && !!process.env.CI.

Associated Travis build can be seen here: https://travis-ci.com/github/dubzzz/fast-check/builds/179306747 (by the way you can see that this job automatically calls yarn --frozen-lockfile)

And uses the following Travis configuration file: https://github.com/dubzzz/fast-check/blob/fa7e754eb5e4c4e348e8813469dbd964a9d70610/.travis.yml

How did you fix it? <!-- A detailed description of your implementation. -->

I changed the error into a warning for Travis CI as suggested by @arcanis on Twitter.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [x] I have verified that all automated PR checks pass.

Any way this can be addressed by Yarn team? (@torifat ?) Currently on [email protected].

You are five minors late, and one major too 🙂

Sounds good to me (intuitively I'd probably try to drop the CI check to only care about TRAVIS, but if that's what is-ci does ... 🤷‍♀️). Can you run yarn version check -i and mark essential and cli for patches (and put the rest on decline)?

Btw, did you try it in practice? You can run yarn set version from sources --branch 1693 to apply it to your own repository.

• [ ] I'd be willing to implement this feature
• [ ] This feature can already be implemented through a plugin

Describe the user story

Is there an alternative to v1's yarn check? My team has done the v2 upgrade but is reliant on yarn check to confirm whether all the modules have been installed as expected.

Note: we are supporting node_modules on v2 and not using the zero install approach (yet).

This command was deprecated a long time ago due to being largely pointless. More details: https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-remove-yarn-check.md

Perhaps an option would be to make ZipFS & co generic on an "options" parameter:

declare const zipFs: ZipFS<NoRelative>;

declare const p: Path<Portable>;
declare const rel: Path<Portable & Relative>;
declare const abs: Path<Portable & Absolute>;

// Doesn't work
zipFs.readFileSync(p);
zipFs.readFileSync(rel);

// Works
zipFs.readFileSync(abs);

This option would default to false (allows relative), but xfs would default to true, for enforced strictness.

What about using & instead of |? Cf Playground Link.

I'd go with \\.pnp\\.[^\\\/]+, and refine if it causes problems in practice.

Just to be sure I understand - the TS playground you shared use the generic parameters, but still has the bogus behaviour you describe, is that expected? Or are those two different problems?

If this bug would affect us even with the generics, perhaps we should open an issue on the TS repo to see if they have an idea what might cause this.

So that's the main problem I can see with this approach. The initial tweet was about a bug where a relative path was unexpectedly resolved relative to the cwd - but apart from that, the construct was technically fine per the fs prototypes: resolve is just fine with both relative and absolute paths.

So to fix the initial issue, we'd either have to type Resolve to forbid relative paths as first parameter (but that would be technically incorrect since the patched fs would still accept both relative and absolute paths), or make xfs a "stricter" version of fs where relative paths aren't allowed as paths.

What do you think about this?

Do you think it would make sense to turn that into "bitfields"? For example, instead of RelativePortablePath, we'd have Path<Portable | Relative> (and Path<Portable> would accept both relative and absolute paths). Might be more scalable, if we want more types of paths? 🤔

Describe the bug

Build scripts launching inside monorepo workspaces can be nondeterministic

To Reproduce

<details> <summary>Reproduction</summary>

await packageJson({
  workspaces: [`packages/common`],
  dependencies: {
      [`common`]: `workspace:*`
  },
  scripts: {
    postinstall: `echo monorepo`
  }
});

await packageJson({
name: `common`,
version: `1.0.0`,
scripts: {
  postinstall: `echo common`
}
}, {cwd: `./packages/common`});

const outFresh = await yarn()
expect(outFresh).toContain(`STDOUT common`)
expect(outFresh).toContain(`STDOUT monorepo`)

const outAdd = await yarn('workspace', 'common', 'add', 'lodash')

expect(outAdd).toContain(`STDOUT common`)
expect(outAdd).toContain(`STDOUT monorepo`)

</details>

Fixed in master

What's the problem this PR addresses?

Yarn is cleaning up its temp folders in the exit event which forces us to use sync IO calls which has a performance impact.

How did you fix it?

Implemented rmtempPromise and call it right after the CLI is done and about to exit, where we can run async IO without problems.

Result

Time spent cleaning up temp folders after a install with a hot cache and lockfile (install-cache-and-lock in the benchmarks)

Benchmark workflow result: Before: https://github.com/yarnpkg/berry/actions/runs/200276519 After: https://github.com/yarnpkg/berry/actions/runs/200408519

Checklist

• [x] I have read the Contributing Guide.
• [x] I have set the packages that need to be released for my changes to be effective.
• [x] I have verified that all automated PR checks pass.

What's the problem this PR addresses?

When running fetchPackageFromCache Yarn checks if the file already exists using existsSync instead of existsPromise blocking the event loop.

How did you fix it?

Changed existsSync to existsPromise, however this caused race conditions (which lead to https://github.com/yarnpkg/berry/pull/1684) so I moved the load logic into loadPackageThroughMutex to make sure any part of the fetch for a specific locator is mutexed.

Result

When testing the gatsby benchmark install-cache-and-lock locally this reduces the time spent in fetchPackageFromCache from 1001ms to 393ms

Before: https://github.com/yarnpkg/berry/actions/runs/200598797 After: https://github.com/yarnpkg/berry/actions/runs/200603660

Checklist

• [x] I have read the Contributing Guide.
• [x] I have set the packages that need to be released for my changes to be effective.
• [x] I have verified that all automated PR checks pass.

I really want to look but the diff is difficult to read due to the GH interface not working super well for diffs 😞 I'll try to improve a bit our patch infra tomorrow to store the changes under JS syntax, and reapply your diff on top of it.

What's the problem this PR addresses?

• A typo was causing incorrect build executions
• The changelog was missing a few items (it still does)
• The incorrect error message was printed when running Yarn from a non-workspace directory
• Yarn wasn't differentiating deprecated versions from non-deprecated ones

How did you fix it?

• Fixed the typo, added tests
• Print a more helpful error message when Yarn is used on something that isn't a workspace
• Deprecated versions won't be used if other versions satisfy the range

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [ ] I have verified that all automated PR checks pass.

What's the problem this PR addresses?

During fetchEverything Yarn fetches the same locators multiple times wasting resources. Though the mutex prevents a full fetch.

How did you fix it?

Make fetchEverything only fetch unique locators, which also fixes the summary when the cache is empty to show No packages were cached - 1911 packages had to be fetched instead of 532 packages were already cached, 1911 had to be fetched

Result When run locally this improves the gatsby benchmark install-cache-and-lock, where there are 532 duplicated locators, by ~500ms.

Before: https://github.com/yarnpkg/berry/actions/runs/200437582 After: https://github.com/yarnpkg/berry/actions/runs/200511894

Checklist

• [x] I have read the Contributing Guide.
• [x] I have set the packages that need to be released for my changes to be effective.
• [x] I have verified that all automated PR checks pass.

That's not true anymore, since the mutex will be assigned in parallel of mutexedLoad. We can leave those callbacks sync, but better remove the comment.

As a rule I prefer to always use explicit callbacks regardless of whether the arguments happen to be mostly compatible or not, to avoid the kind of problems you get with .map(something).

  process.once(`exit`, () => {
    xfs.rmtempSync();
  });

Same

I'd move that after the xfs.removePromise. This way, even if it doesn't get removed right now, it might get removed once the program exits.

There's .pnp.data.json under certain configurations, so better just use a wildcard

There's .pnp.data.json under certain configurations, so better just use a wildcard

• [ ] I'd be willing to implement a fix

Describe the bug

plugin-interactive-tools marks a deprecated version, not tagged as "latest", as "Range/Latest" and suggests updating to it.

The line presented to me in upgrade process:

? Pick the packages you want to upgrade.          Current          Range/Latest
 … 
 > @wojtekmaj/predict-input-value                 ◉  ^1.0.0        ◯  ^1.1.0

Quick look at npm api results for this package reveals that:

• 1.1.0 is indeed highest version number, BUT
• Tag "latest" is set to 1.0.0:

  "dist-tags": {
    "latest": "1.0.0"
  },
  

• 1.1.0 is deprecated:

  "versions": {
    "1.1.0": {
      "name": "@wojtekmaj/predict-input-value",
      "version": "1.1.0",
      …
      "deprecated": "Mistakenly released"
    }
    "1.0.0": { … }
  },
  

To Reproduce

I hope the information above is enough, but let me know if you need even more information.

Environment if relevant (please complete the following information):

• OS: [e.g. OSX, Linux, Windows, ...] macOS
• Node version [e.g. 8.15.0, 10.15.1, ...] 14.5.0
• Yarn version [e.g. 2.0.0-rc1, ...] 2.1.1

Should be fixed by https://github.com/yarnpkg/berry/pull/1683

• [ ] I'd be willing to implement a fix

Describe the bug

I am using yarn on Windows. This is the workspaces definition:

  "workspaces": [
    "packages/*",
    "mobile"
  ],

If the path listed is not an exact-case match to the current directory, then yarn install will fail with:

d:\git\Website\Mobile>yarn install
Usage Error: This command can only be run from within a workspace of your project (Mobile isn't a workspace of /d:/git/Website/package.json).

Windows treats paths as case-insensitive, so I would expect yarn to do so as well. This problem is exacerbated by the fact that if you use PowerShell as your shell, it lets you cd into a directory with any casing variant you want. (cmd, on the other hand, seems to always use the casing on disk regardless of what you type.)

To Reproduce

Create directory structure as follows:

\Test
   \packages
      \a
   \Mobile

Add a package.json to the root:

{
  "name": "test",
  "description": "test Monorepo",
  "private": true,
  "workspaces": [
    "packages/*",
    "mobile"
  ]
}

Add a basic package.json to the packages/a and Mobile directories.

Run yarn install from Mobile.

Environment if relevant (please complete the following information):

• OS: Windows
• Node version: 12.18.1
• Yarn version 2.1.1

I think it's fine to be case-sensitive. Generally speaking, we try to enforce that projects are as portable as possible, and in this case there is very little benefits in supporting accesses through different path cases (similarly, if you run require('foo/PACKAGE.JSON'), it won't work under PnP even though it would have with node_modules).

That said there was a display issue - the error message we print should have been much more descriptive, but a bug was causing the incorrect one to be displayed. This will be fixed with https://github.com/yarnpkg/berry/pull/1683.

What's the problem this PR addresses?

• A typo was causing incorrect build executions
• The changelog was missing a few items (it still does)
• The incorrect error message was printed when running Yarn from a non-workspace directory
• Yarn wasn't differentiating deprecated versions from non-deprecated ones

How did you fix it?

• Fixed the typo, added tests
• Print a more helpful error message when Yarn is used on something that isn't a workspace
• Deprecated versions won't be used if other versions satisfy the range

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [ ] I have verified that all automated PR checks pass.

Thanks!

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

promise-inflight requires Bluebird, and then falls back to native Promise (https://git.io/JJP8d). However, Bluebird is not declared as peer dependencies. (https://github.com/iarna/promise-inflight/pull/4)

promise-inflight has 12M weekly downloads.

How did you fix it? <!-- A detailed description of your implementation. -->

Added promise-inflight to compat extensions.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [x] I have verified that all automated PR checks pass.

Which CI? We have a CI mode under which only a summary is printed. Perhaps your CI isn't well detected?

Curious - afaik Webpack 5 also simply requires pnpapi, I don't know why it would still be transpiled 🤔

I don't like 100 YN0013 messages with can't be found in the cache and will be fetched from the remote registry

Can it be hidden somehow by default?

Not reverted, and we don't have a regression as far as I'm aware. Feel free to open an issue with the relevant info (including screenshots, and potentially investigating yourself why would the logs be printed) if you believe this comes from Yarn.

That would be ideal! In fact, if you can ignore .pnp.* it would probably be the best - we'll likely change the file name to .pnp.cjs in the next major, otherwise it causes problem with projects configured for ESM.

No (because the lockfile would effectively be pruned from extraneous entries, should it be persisted, so it wouldn't pass the immutable check) - I'd recommend to run the full yarn install --immutable as a CI validation step.

Reopening as we prefer to keep feature discussions in this repository, at least at the moment.

If I understand correctly, you'd like a list of packages with known "safe" postinstall scripts.

I think that's a fair request, and it almost certainly can be implemented in a plugin, but I don't think our org will take the responsibility of maintaining such a list - first because we would probably prefer to adopt a neutral point of view, but also because we simply don't have the bandwidth. Last reason, we are discouraging postinstall scripts altogether, and maintaining a list of "blessed packages" would got in the opposite way.

Rendered

Ah nevermind, I misunderstood your PR, you're talking about security, not compatibility. I'll close this RFC and reopen the issue to discuss it, as we don't really use this repository anymore.

It's already the case! The compat plugin contains various builtin extensions - we just need to fill it more aggressively, but since we require to also send a PR upstream, it takes a bit of time that core maintainers don't always have:

https://github.com/yarnpkg/berry/blob/master/packages/plugin-compat/sources/extensions.ts

It's not locked as spam, though

https://github.com/yarnpkg/yarn/issues/4563

Googling an error arrived at what looks like the exact error described in the above issue.

The issue is opened, but locked as 'spam'. Is that a mistake?

It would be handy to be able to still discuss that issue.

Can't check right now, but I suspect babel-jest is transpiling the .pnp.js file, which it shouldn't do for the reason described in the error message. I'd suggest to try disabling transforms on this file.

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

• ZipFS doesn't currently support read after write.
• truncate isn't currently implemented
• link isn't currently implemented
• chown isn't currently implemented
• It's hard to tell apart libzip errors from regular errors

How did you fix it? <!-- A detailed description of your implementation. -->

• I've added a file source cache, which makes read-after-write operations completely bypass libzip
• I've implemented truncate (also in ZipFS)
• I've implemented link (not in ZipFS, since Zip archives don't support hardlinks. I think a solution would be to fully mock the behavior of hardlinks while having the hardlinked files stored on disk once for each entry. Is this a good idea?)
• I've implemented chown (not in ZipFS, I can't think of any way to implement it there. Any ideas?)
• Libzip errors are now special: they have a Libzip Error name and a code (e.g. ZIP_ER_CHANGED). I've also made ZipFS throw Assertion failed: unexpected libzip error when it encounters ZIP_ER_CHANGED since it should now be impossible for that to happen.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [ ] I have verified that all automated PR checks pass.

I agree with this semantic 👍 Not sure about hardlinks support though - they are very different, as changing one won't change the other. A code expecting a hardlink to work could get really weird bugs 🤔

The first issue is how to distribute the plugin to the users. People just do git clone and yarn install and expect everything to be ready. Now we will expect them to do another step as well: yarn plugin import https://xxxxx/plugin.js.

Note that plugins are meant to be checked-in (same as the Yarn binary itself), so cloning is all that's required to have a working environment.

There are a few other implementations where len must be made optional

  async truncatePromise(p: PortablePath, len: number = 0) {

  async truncatePromise(p: PortablePath, len?: number) {

I used ENOSYS for other "not implemented" errors, is there a reference for when to use EOPNOTSUPP?

  truncateSync(p: PortablePath, len: number = 0) {

  truncateSync(p: PortablePath, len?: number) {

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

https://github.com/yarnpkg/berry/pull/1597 switched all mkdirp calls to mkdir(?, {recursive: true}) to improve performance, but didn't take into account that there's an important difference between the 2 functions: mkdirp doesn't throw if a non-folder basename already exists, while mkdir(?, {recursive: true}) does.

This problem caused all cross-drive movePromise calls (in other words, all cross-drive mirror-to-cache moves) to throw if the destination already existed.

How did you fix it? <!-- A detailed description of your implementation. -->

I made it so that mkdir(?, {recursive: true}) EEXIST errors are ignored inside copyPromise.

I also added a test.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [x] I have verified that all automated PR checks pass.

Really nice! That file: never updated always was a pain 😃

What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) -->

Packages referenced using the file: protocol don't update their cache entry when their contents change.

How did you fix it? <!-- A detailed description of your implementation. -->

I made the checksum of the archive a part of the file: locator, which makes it automatically update the cache entry when changed.

Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an x in all the boxes that apply. -->

• [x] I have read the Contributing Guide.

<!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with yarn version check and fix with yarn version check -i -->

• [x] I have set the packages that need to be released for my changes to be effective.

<!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. -->

• [ ] I have verified that all automated PR checks pass.

Hi,

I've tried to use the new version of yarn with the --ignore-scripts. This flag has been removed from the v2. Why though? I've always found it to be a little bit of a security layer when installing any script/package. Is this on purpose? Will it ever come back again? Or it's something that has been deemed as unnecessary and no longer will be supported?

Would love to know about this, when you have the time. All-in-all keep up the good work! 💪

Generally speaking, a lot of command line flags have been moved to the configuration settings. For example, --ignore-scripts is now available as enableScripts.

The reason for this is that those flags were defining persistent behaviors (ie things that you want to apply to every install, not just a single one), so they were ill-suited to CLI options (for example, running yarn add would also trigger an install, so you had to remember to add the --ignore-scripts flag ... who did it?).

• I'm not sure why you want to have both a plugin and a package - I'd suggest to avoid that and simply include everything into the plugin. If you want to have a package to use it with other package managers too, imo you should just bundle it inside the plugin (the builder will do this) and just distribute the Yarn plugin to users.

• I'd also avoid the postinstall and the unplug. I don't know how many statics you have, but with the current single-file model you'd rather bundle the assets inside the JS - it's a bit weird, I agree, but usually there aren't that many images within plugins 😄

It remains however a bit unclear in the current documentation and in the current behavior of yarnpkg-builder how this feature fits into the larger ecosystem

That's true! It's because we didn't put much thought into that yet 😅

Given the already large number of changes in the v2, we preferred to implement low-level tools and figure out the next high-level layers based on community feedback during the next months. Plugins are one of those things that are a bit rough at the moment until we can figure out a better user story.

builder build plugin always normalizes the plugin name to '@yarnpkg/xxxxx'. It's not clear today if this is intended or if there is something more that we need to know,

It's intended...ish. The normalization was made so that people could in theory override the builtin plugins (like essentials) with their own implementations. In practice I'm not sure it works, and I'm even less sure it's a valid use case. I'd be ok with removing this limitation.

yarn plugin import has different treatment depending on whether the plugin is hosted on yarnpkg repo or not. If not, it has to be a downloadable single file bundle. Why we can't just ship third-party plugins as npm modules, add them as dev deps, and then yarn can just import from there, like usual?

Because, just like the Yarn bundle itself, plugins cannot have dependencies (chicken and egg problem; if you have dependencies you need to run an install, but to run an install you need the plugins to be registered).

So I figured the easiest way to distribute them would be as single JS files (just like the regular CLI), and thus using the npm registry didn't really provide anything of value (since you need to download a tgz which may contain many files).

even when a plugin is imported from the local filesystem, yarn plugin import builds a different cjs file. Not clear how is that working with builder and if we (as plugin developers) need to know about it.

Not sure what you mean - iirc we just copy it into the local directory and add it to the configuration.

On a separate note, if you want safety in linking nm, I think you're looking for a similar algorithm to the one used by pnpm - not nohoist. I'd be very interested to see that implemented in Yarn, although someone would have to take ownership of its implementation.

I agree it could be improved - if someone wants to give a PR a try, go for it!

The main point of the nm linker is to make the migration from Yarn 1 to Yarn 2 easier, for people who can't switch to PnP yet. For this to be true, we cannot make semi-large changes like this... for now.

Yarn will keep having major releases (more frequently than before, likely one per year), so I'm open to revisit this in one of them, depending how far in the migration process we are.

For now, however, the nm linker must be as low friction as possible.

Fwiw we have since then started to use Clipanion.

↪️ Pull Request

The latest release is missing a dependency, so tests are failing: https://github.com/yarnpkg/berry/runs/947729059?check_suite_focus=true

✔️ PR Todo

• [ ] Added/updated unit tests for this change
• [ ] Filled out test instructions (In case there aren't any unit tests)
• [x] Included links to related issues/PRs

I'm not a fan of using environment variables for this, because it'll break people using zero-installs (when the cache is inside the repository), overriding the config they explicitly requested (I know it's what the code already did, overriding --cache-folder etc, but that really strikes me as a bad idea).

I think a more gentle approach would be to create a .yarnrc.yml file in the home directory that would contain the "default options" you want to have. This way, users would still be able to opt-out of the default workflow to use their own.

    echo "Global yarn version ($(yarn --version)) that doesn't match expected ($yarn_version)"