YYarn BotSync master with the changes from master

57081c05创建于 7月29日历史提交

文件	最后提交记录	最后更新时间
sources	feat(builder): transform `node:` imports as needed (#6356) ## What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) --> Yarn plugins used to be forbidden to import/require built-in modules prefixed with `node:`. see #6135 see #5417 Fixes #5637 The yarn plugin builder should be aware of this fact and produce bundled code, that does not contain any `node:` prefixed import/require. This is especially important when building plugins with 3rd party dependencies, where the plugin author cannot "fix" the imports to yarn's needs. ## How did you fix it? <!-- A detailed description of your implementation. --> I enabled the plugin-compiler to generate the plugin-code as needed: I utilized the capability of `esbuild` to strip these `node:` prefixes from import/require instructions. Therefore, I added config options to the plugin build process to instruct `esbuild` to do so. This is a fix of the plugin builder, which enables plugin authors to compile their work in a backwards-compatible way, so that the build result is runnable in old/unpatched versions of yarn. Unpatched regarding #5997 ## Related The #5997 tries to address the issue from the plugin-runtime side. This would enable "broken" plugins to be runnable in all future/patched versions of yarn-core. ## Additionally This very PR aims to enable plugin authors to create plugins that are runnable with unpatched versions of yarn-core. It is considered a friction-free backwards-compatible solution on all ends. Yet it does not replace #5997. ## 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](https://yarnpkg.com/advanced/contributing). <!-- 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 will check that all automated PR checks pass before the PR gets reviewed. --------- Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com> Co-authored-by: Maël Nison <nison.mael@gmail.com>	2 年前
README.md	Generate CLI docs as a Docusaurus plugin (#6218) What's the problem this PR addresses? The current method of CLI docs generation is very inefficient because it is synchronously blocking and memory-intensive. It can easily take up 40% of the time needed to start the dev server. How did you fix it? Created a Docusaurus plugin that generates the CLI docs. This has a number of advantages over the existing method: - It is async and happens in parallel to other Docusaurus plugins, thus much faster in terms of total build time. - It is written in TypeScript, so type-checked and has better DX - It obtains the command definitions by running the TypeScript source directly instead of going through a shell, saving overhead - It writes the result to disk via Docusaurus APIs, saving memory ### Performance ``` # Before Warm dev startup Time (mean ± σ): 68.887 s ± 1.508 s [User: 114.795 s, System: 18.496 s] Range (min … max): 67.447 s … 71.328 s 5 runs Cold dev startup Time (mean ± σ): 68.346 s ± 0.204 s [User: 104.264 s, System: 15.938 s] Range (min … max): 68.195 s … 68.675 s 5 runs Warm Build Time (mean ± σ): 110.748 s ± 0.781 s [User: 139.832 s, System: 15.310 s] Range (min … max): 109.902 s … 111.528 s 5 runs Cold Build Time (mean ± σ): 306.749 s ± 10.032 s [User: 1588.512 s, System: 300.103 s] Range (min … max): 298.550 s … 322.576 s 5 runs # After Warm dev startup Time (mean ± σ): 42.410 s ± 0.546 s [User: 60.527 s, System: 6.049 s] Range (min … max): 41.807 s … 43.265 s 5 runs Cold dev startup Time (mean ± σ): 42.275 s ± 0.326 s [User: 59.571 s, System: 5.824 s] Range (min … max): 41.760 s … 42.657 s 5 runs Warm Build Time (mean ± σ): 85.861 s ± 2.109 s [User: 95.237 s, System: 5.144 s] Range (min … max): 83.617 s … 88.499 s 5 runs Cold Build Time (mean ± σ): 149.498 s ± 7.973 s [User: 440.898 s, System: 15.700 s] Range (min … max): 140.074 s … 160.208 s 5 runs ``` ### Index pages I have also taken the opportunity to take the `@yarnpkg/cli` index page and adapted it to the other binaries ### ⚠️ URL changes Unfortunately, generating the CLI docs as a separate plugin makes the original URL scheme conflict with the main docs plugin, so we either have to - move all generated CLI docs under a single path prefix (e.g. `/cli`) - lose state (in particular, sidebar scroll state) when navigating between pages for different binaries I have opted to move everything under `/cli` ### Other Changes The change causes a few visual changes to existing stuff: - The previous page and next page links have been removed. Should be easy to recreate but I don't feel like they have much value - The sidebar is now sorted in lexicographical order - The additional binaries' examples now include the `yarn` invocation, and thus is properly styled - Very minor, but the column widths in the options table have shifted very slightly ### Future work This PR is ready, but I am still experimenting with a few things that may or may not make it into the PR. - <s>I'm trying whether it is possible to use Docusaurus's watch mechanism to hot rebuild the pages.</s> - <s>Also, as you can see, there are practically no difference in warm and cold startup time. Maybe checking mtimes can avoid some work?</s> 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](https://yarnpkg.com/advanced/contributing). <!-- 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 will check that all automated PR checks pass before the PR gets reviewed.	2 年前
package.json	Sync master with the changes from master	1 个月前

@yarnpkg/builder

A CLI tool designed for creating, building, and managing complex plugins.

This version of the builder is for creating plugins for Yarn 3.x. Yarn 3 plugins are not compatible with Yarn 2 installations, however Yarn 2 plugins are usually compatible with Yarn 3. If you wish to create plugins for Yarn 2, please use v2.x of the builder (yarn add @yarnpkg/builder@^2).

Features

builder new plugin command for scaffolding new plugins
builder build plugin command for building complex plugins
supports TypeScript out-of-the-box
uses ESBuild internally, providing treeshaking, minification, and various other optimizations out-of-the-box

Installation

yarn add -D @yarnpkg/builder

Commands

builder new plugin - Create a new plugin.
builder build plugin - Build a local plugin.
builder build bundle - Build a yarn.js bundle from our repository (internal).