Enables all official plugins by default

[arcanis]

What's the problem this PR addresses?

While the plugin architecture is useful to enforce proper separation of concerns, having our official features in multiple plugins isn't very good from a pure UX perspective and only enables smaller bundles. With Corepack becoming the recommended install strategy size is less of a concern (especially given the reasonably average size impact), so we can afford to add all plugins in the standard distribution.

This doesn't affect the plugin feature itself: third-party plugins will keep being supported, and there are no plans to stop providing the exact same API we currently expose.

How did you fix it?

Enables all plugins in the build config.

Checklist

• I have read the Contributing Guide.

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

• I will check that all automated PR checks pass before the PR gets reviewed.

[merceyz]

What's the performance impact of loading all the plugins?

[paul-soporan]

I don't think we should automatically add @types/ dependencies by default. Since previously the plugin wasn't bundled, importing it served as a good opt-in check, but now we should probably use a heuristic to only add it if the project depends on typescript (though there should probably be a config option for it too so that people that really want a better editor experience without type-checking can force it too 🤔).

[arcanis]

What's the performance impact of loading all the plugins?

I'll have to rework @yarnpkg/libui; the runtime cost is a little large at the moment:

Benchmark #1: YARN_IGNORE_PATH=1 node ./current.js --version
  Time (mean ± σ):     282.5 ms ±   2.0 ms    [User: 280.6 ms, System: 33.6 ms]
  Range (min … max):   279.5 ms … 285.0 ms    10 runs

Benchmark #2: YARN_IGNORE_PATH=1 node ./all-plugins.js --version
  Time (mean ± σ):     406.4 ms ±   3.8 ms    [User: 421.9 ms, System: 39.7 ms]
  Range (min … max):   402.7 ms … 415.5 ms    10 runs

Summary
  'YARN_IGNORE_PATH=1 node ./current.js --version' ran
    1.44 ± 0.02 times faster than 'YARN_IGNORE_PATH=1 node ./all-plugins.js --version'

[arcanis]

It seems to be much more reasonable when taking v8-compile-cache into account (which is what Corepack automatically enables):

Benchmark #1: YARN_IGNORE_PATH=1 node -r $V8CC ./current.js --version
  Time (mean ± σ):     242.6 ms ±   3.2 ms    [User: 246.4 ms, System: 30.8 ms]
  Range (min … max):   238.7 ms … 247.2 ms    11 runs

Benchmark #2: YARN_IGNORE_PATH=1 node -r $V8CC ./all-plugins.js --version
  Time (mean ± σ):     341.0 ms ±   3.2 ms    [User: 359.5 ms, System: 38.6 ms]
  Range (min … max):   336.3 ms … 347.2 ms    10 runs

Benchmark #3: YARN_IGNORE_PATH=1 node -r $V8CC packages/yarnpkg-cli/bundles/yarn.js --version
  Time (mean ± σ):     274.2 ms ±  26.8 ms    [User: 274.3 ms, System: 34.1 ms]
  Range (min … max):   263.9 ms … 350.5 ms    10 runs

[merceyz]

We should print some kind of warning that users are overriding builtin plugins, otherwise people might forget to remove plugins that are now shipped by default from their projects.

[merceyz]

A few minor details otherwise looks good. Any thoughts on #4253 (review)?

[merceyz]

Should check this when removing dependencies as well

[paul-soporan]

I'm not entirely sure I agree with this - while adding @types should only happen when the user uses TS, they can be safely removed even when the user doesn't, since @types/foo will always be related to foo.

[merceyz]

The documentation (

berry/README.md

Lines 213 to 223 in 4ffd908

	### Contrib plugins
	Although developed on the same repository as Yarn itself, those plugins are optional and need to be explicitly installed through `yarn plugin import @yarnpkg/<plugin-name>`.
	- [☆ plugin-constraints](packages/plugin-constraints) adds support for [constraints](https://yarnpkg.com/features/constraints) to Yarn.
	- [☆ plugin-exec](packages/plugin-exec) adds support for using the [`exec:`](https://github.com/yarnpkg/berry/tree/master/packages/plugin-exec#documentation) protocol within your dependencies.
	- [☆ plugin-interactive-tools](packages/plugin-interactive-tools) adds support for various interactive commands ([`yarn upgrade-interactive`](https://yarnpkg.com/cli/upgrade-interactive)).
	- [☆ plugin-stage](packages/plugin-stage) adds support for the [`yarn stage`](https://yarnpkg.com/cli/stage) command.
	- [☆ plugin-typescript](packages/plugin-typescript) improves the user experience when working with TypeScript.
	- [☆ plugin-version](packages/plugin-version) adds support for the new [release workflow](https://yarnpkg.com/features/release-workflow).
	- [☆ plugin-workspace-tools](packages/plugin-workspace-tools) adds support for the [`yarn workspaces foreach`](https://yarnpkg.com/cli/workspaces/foreach) command.

etc.) needs an update as well and the release script can be simplified a bit

berry/.github/workflows/release-candidate.yml

Lines 34 to 41 in b4d08fa

	yarn build:cli $(
	yarn constraints query "
	workspace(Cwd),
	workspace_field(Cwd, 'scripts["update-local"]', _),
	workspace_ident(Cwd, Ident),
	sub_atom(Ident, 0, _, _, '@yarnpkg/plugin-')
	" --json | jq -r '"--plugin='$(pwd)'/" + .Cwd' | xargs
	)

[arcanis]

Any thoughts on #4253 (review)?

I agree, but for now I'd prefer to land this PR without adding too much delay; I'll keep that in mind for a followup.

[merceyz]

Doesn't seem like we can update this file without breaking Yarn v3

berry/packages/plugin-essentials/sources/commands/plugin/list.ts

Line 6 in b433198

const REMOTE_REGISTRY = `https://raw.githubusercontent.com/yarnpkg/berry/master/plugins.yml`;

[arcanis]

Indeed - at the very least I'll update the urls to point on the 3.2 tag rather than master.