master

文件	最后提交记录	最后更新时间
advanced	Fix: Names the Experimental ESM support warning (#7069) Names the ESM experimental loading warning ## What's the problem this PR addresses? Simple justification: unnamed logs should be avoided More complex justifiation: Lots of workspaces now are esm by default. This warning will appear on all of them. While it is "true", there is a strong desire to filter it out so that it does not: - cause others to ignore genuine warnings - make identifying warnings in CI overly complex, (partially address #7066) Unnamed logs cannot be filtered. ## How did you fix it? I've added a new name for the warning, and made the warning use that name ## Checklist - [x] I have read the [Contributing Guide](https://yarnpkg.com/advanced/contributing). - [x] I have set the packages that need to be released for my changes to be effective. - [x] I will check that all automated PR checks pass before the PR gets reviewed. Co-authored-by: Normal Gaussian <gitlab.march.2019@normal-gaussian.com>	6 个月前
configuration	Migrate docs to Docusaurus v3 (#6133) **What's the problem this PR addresses?** <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) --> The docs website is on Docsaurus v2 which is not the latest major version Closes #5918 Closes #6153 **How did you fix it?** <!-- A detailed description of your implementation. --> Migrate to Docsaurus v3. There are other improvements to the build process and website I'd like to make, but I have left them out and kept most of the logic intact since the migration is quite a large undertaking already. **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 年前
features	docs: remove peerDependencies from catalog supported fields (#7230) The docs list `peerDependencies` as supported for `catalog:`, but it isn't yet: it resolves to `*` (see #6925, fix proposed in #6926). Removing it from the list until that lands.	2 个月前
getting-started	feat: Add editor SDK support for oxc (oxfmt & oxlint) (#7078) ## What's the problem this PR addresses? Add editor SDK support for oxc. This should enable optional editor integration with both oxfmt and oxlint. ## How did you fix it? Added oxlint, oxfmt and oxlint-tsgolint as supported integration and documented it. Oxlint and oxlint-tsgolint addition is a bit hacky and I don't know whether this is the right direction or not. Rationale can be read from the comment there. Loader option added to sdk setupEnv to prevent oxfmt tinypool from being broken due to failing to resolve tinypool/dist/process.js. I haven't tried this with vim yet since I don't use it so if anyone would kindly help test whether this will work on vim or not, thanks! ### oxlint type-aware feature (tsgolint) The biggest challenge here is the type-aware feature (tsgolint) support. The rust side of oxlint spawn tsgolint a bit different from how the oxlint itself is spawned: https://github.com/oxc-project/oxc/blob/d3dcf5bc9718ebb4839be27062b5d82da2118e2e/crates/oxc_linter/src/tsgolint.rs#L265-L270 Instead of using js entrypoint, it directly spawn executable so the wrapper approach is not directly applicable here. Luckily, there are some strategies that the oxc_linter uses to resolve tsgolint: - via PATH - via node_modules search - direct path via OXLINT_TSGOLINT_PATH (which is what oxc.path.tsgolint does basically) The only realistic strategy is to use PATH. For the sdks, it will generate a windows executable shim (cmd) that will basically just spawn tsgolint.js, else should fallback to tsgolint. Be noted however that this will not fix fundamental issue with typescript-go module resolution, which requires this to be merged first: - https://github.com/microsoft/typescript-go/pull/1966 This PR just enable the usage of tsgo regardless of whether it can resolve with pnp or not in the type-checking. ### Reference Coc config: https://github.com/oxc-project/coc-oxc/blob/7a7f0d8f503d5cdb65da37232da6b865f159b42a/src/common.ts#L27-L36 Vscode oxc binary resolution reference: https://github.com/oxc-project/oxc-vscode/blob/main/client/findBinary.ts Oxlint-tsgolint executable resolution: https://github.com/oxc-project/oxc/blob/d3dcf5bc9718ebb4839be27062b5d82da2118e2e/crates/oxc_linter/src/tsgolint.rs#L1164-L1225 ## Checklist - [x] I have read the [Contributing Guide](https://yarnpkg.com/advanced/contributing). - [x] I have set the packages that need to be released for my changes to be effective. - [x] I will check that all automated PR checks pass before the PR gets reviewed.	4 个月前