| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
chore(deps): upgrade `sigstore` to v4 (#7208) ## What's the problem this PR addresses? This PR bumps vulnerable dependency `sigstore` from v3 to v4, which resolves https://github.com/advisories/GHSA-52v5-jr5w-gjxr, https://github.com/advisories/GHSA-jfc7-64v2-mr8c, and https://github.com/advisories/GHSA-xgjw-pm74-86q4. Changelog: https://github.com/sigstore/sigstore-js/blob/main/packages/client/CHANGELOG.md#400 ## How did you fix it? I bumped `sigstore` in `package.json`. ## 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: Maël Nison <nison.mael@gmail.com> | 1 个月前 | |
Releasing 2 new packages | Package name | Version | | --- | --- | | `@yarnpkg/cli` | `4.18.1` | | `@yarnpkg/core` | `4.9.2` | | 3 天前 | |
Version: Reimplement `yarn version` and `yarn version apply` (#7218) <!-- IMPORTANT: While Yarn 4.x is still actively developed we're now focusing work on our next major releases (5.x and 6.x). These sister releases use the same pattern as TypeScript-Go: - 5.x will only contain a handful of breaking changes to provide a safe migration path. - 6.x will be the "true" release, notable for being implemented in Rust and including a significantly improved core. While PRs can still be opened against 4.x, we recommend power users to try Yarn 6.x now and help us get it over the finish line. It uses the same testsuite as Berry, so compatibility should be at its best. To check out the working trunk for Yarn 6.x, please refer to this repository: https://github.com/yarnpkg/zpm --> ## What's the problem this PR addresses? The `yarn version` family of commands has a number of unintuitive behaviors. The most prominent ones are: - Immediate mode in a git repo requires history because it is implemented as a `yarn version --deferred` + `yarn version apply` - For dealing with prereleases, it uses a relatively less-known `stableVersion` field in addition to the `version` field which interacts unintuitively with some workflows. In particular, deferring a semver strategy resolves a named strategy against `version`, which `yarn version apply` applies to `stableVersion` Fixes #3868 Fixes #4014 Fixes #4328 Fixes #5224 Fixes #6810 Fixes #6857 Fixes #6860 Fixes #6970 Fixes #7025 Closes #7110 (supercedes) ## How did you fix it? Reimplemented the `yarn version` and `yarn version apply` commands. Now the bumping logic resides in `yarn version --immediate`. Instead of `yarn version --immediate` being implemented as `yarn version --deferred` + `yarn version apply`, now `yarn version apply` is implemented as `yarn version --immediate decline`. This alleviates the git history requirement of `yarn version --immediate` The prerelease bumping logic is also refactored to be more predictable and can be calculated from a single version, without relying on storing an additional `stableVersion`. Simply put, if the current version is `1.2.0-3`, `prepatch` and `preminor` both bump it to `1.2.0-4` and `premajor` bump it to `2.0.0-0`. `prerelease` is effectively same as `prepatch`. Now that `stableVersion` is not needed, `yarn version --immediate` and `yarn version apply` will remove them from any bumped workspaces. (Our own release pipeline also writes the `stableVersion` field but I don't know if there is a purpose. So I have left them alone for now) The `--prerelease` flag also have some bug fixed. For example, when applying a `prerelease` bump to `1.2.3-alpha.1` with prerelease pattern `beta.%n`, you'd end up with `1.2.3-alpha.1-beta.1`... Also, given how easily "bumping" to a version lower than the current one can happen accidentally due to how prereleases work, there is also now a check to stop that and a `--force` flag to suppress that check. The command documentation has been rewritten and many tests have been added to rigorously document these behavior. ## 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. --------- Co-authored-by: Maël Nison <nison.mael@gmail.com> | 1 个月前 | |
refactor: update `esbuild` and remove `esbuild-plugin-pnp` (#4732) * refactor: Deprecate esbuild-plugin-pnp * Update e2e workflow * Update .yarn/versions/ded9c7c0.yml Co-authored-by: Kristoffer K. <merceyz@users.noreply.github.com> * deps: `esbuild-wasm@0.15.3` * deps: `esbuild-wasm@0.15.5` * chore: remove `baseUrl` * Fixes use strict * Restores the readme to explain the deprecation Co-authored-by: Kristoffer K. <merceyz@users.noreply.github.com> Co-authored-by: Maël Nison <nison.mael@gmail.com> | 3 年前 | |
Sync master with the changes from master | 3 个月前 | |
feat(plugin-npm): add npm provenance support (#6750) ## What's the problem this PR addresses? <!-- Describe the rationale of your PR. --> <!-- Link all issues that it closes. (Closes/Resolves #xxxx.) --> Hi! I added support for provenance to `yarn npm publish`. Closes #5430 ## How did you fix it? <!-- A detailed description of your implementation. --> Adapted code from npm to produce a provenance signature in supported CI environment. ## 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. ## Next steps - Update https://github.com/npm/documentation/blob/c2efb649816e27d37b37da2b21200e4c9ade0d17/content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx?plain=1#L124 | 1 年前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Version: Reimplement `yarn version` and `yarn version apply` (#7218) <!-- IMPORTANT: While Yarn 4.x is still actively developed we're now focusing work on our next major releases (5.x and 6.x). These sister releases use the same pattern as TypeScript-Go: - 5.x will only contain a handful of breaking changes to provide a safe migration path. - 6.x will be the "true" release, notable for being implemented in Rust and including a significantly improved core. While PRs can still be opened against 4.x, we recommend power users to try Yarn 6.x now and help us get it over the finish line. It uses the same testsuite as Berry, so compatibility should be at its best. To check out the working trunk for Yarn 6.x, please refer to this repository: https://github.com/yarnpkg/zpm --> ## What's the problem this PR addresses? The `yarn version` family of commands has a number of unintuitive behaviors. The most prominent ones are: - Immediate mode in a git repo requires history because it is implemented as a `yarn version --deferred` + `yarn version apply` - For dealing with prereleases, it uses a relatively less-known `stableVersion` field in addition to the `version` field which interacts unintuitively with some workflows. In particular, deferring a semver strategy resolves a named strategy against `version`, which `yarn version apply` applies to `stableVersion` Fixes #3868 Fixes #4014 Fixes #4328 Fixes #5224 Fixes #6810 Fixes #6857 Fixes #6860 Fixes #6970 Fixes #7025 Closes #7110 (supercedes) ## How did you fix it? Reimplemented the `yarn version` and `yarn version apply` commands. Now the bumping logic resides in `yarn version --immediate`. Instead of `yarn version --immediate` being implemented as `yarn version --deferred` + `yarn version apply`, now `yarn version apply` is implemented as `yarn version --immediate decline`. This alleviates the git history requirement of `yarn version --immediate` The prerelease bumping logic is also refactored to be more predictable and can be calculated from a single version, without relying on storing an additional `stableVersion`. Simply put, if the current version is `1.2.0-3`, `prepatch` and `preminor` both bump it to `1.2.0-4` and `premajor` bump it to `2.0.0-0`. `prerelease` is effectively same as `prepatch`. Now that `stableVersion` is not needed, `yarn version --immediate` and `yarn version apply` will remove them from any bumped workspaces. (Our own release pipeline also writes the `stableVersion` field but I don't know if there is a purpose. So I have left them alone for now) The `--prerelease` flag also have some bug fixed. For example, when applying a `prerelease` bump to `1.2.3-alpha.1` with prerelease pattern `beta.%n`, you'd end up with `1.2.3-alpha.1-beta.1`... Also, given how easily "bumping" to a version lower than the current one can happen accidentally due to how prereleases work, there is also now a check to stop that and a `--force` flag to suppress that check. The command documentation has been rewritten and many tests have been added to rigorously document these behavior. ## 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. --------- Co-authored-by: Maël Nison <nison.mael@gmail.com> | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 3 天前 | |
Sync master with the changes from master | 3 天前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 5 个月前 | |
Sync master with the changes from master | 5 个月前 | |
fix(fslib): handle float timestamps in convertToBigIntStats (#6988) ## Summary Fixes RangeError when converting floating-point timestamps to BigInt in the `convertToBigIntStats` function. ## Problem The `convertToBigIntStats()` function fails when file stats contain non-integer timestamps (e.g., `1763746784088.47`), throwing: ``` RangeError: The number 1763746784088.47 cannot be converted to a BigInt because it is not an integer ``` This occurs when ZIP file entries have timestamps with floating-point precision, particularly observed in Yarn 6.0.0-rc.5 when building with Storybook. ## Solution Use `Math.floor()` to ensure integer values before BigInt conversion on line 194 of `packages/yarnpkg-fslib/sources/statUtils.ts`. ## Changes - Changed `BigInt(element)` to `BigInt(Math.floor(element))` ## Testing - Tested with Yarn 6.0.0-rc.5 + Storybook build - Verified the RangeError no longer occurs with floating-point timestamps ## Related This issue was discovered while running `yarn storybook build` with Yarn 6.0.0-rc.5. --------- Co-authored-by: Maël Nison <nison.mael@gmail.com> | 9 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Version: Reimplement `yarn version` and `yarn version apply` (#7218) <!-- IMPORTANT: While Yarn 4.x is still actively developed we're now focusing work on our next major releases (5.x and 6.x). These sister releases use the same pattern as TypeScript-Go: - 5.x will only contain a handful of breaking changes to provide a safe migration path. - 6.x will be the "true" release, notable for being implemented in Rust and including a significantly improved core. While PRs can still be opened against 4.x, we recommend power users to try Yarn 6.x now and help us get it over the finish line. It uses the same testsuite as Berry, so compatibility should be at its best. To check out the working trunk for Yarn 6.x, please refer to this repository: https://github.com/yarnpkg/zpm --> ## What's the problem this PR addresses? The `yarn version` family of commands has a number of unintuitive behaviors. The most prominent ones are: - Immediate mode in a git repo requires history because it is implemented as a `yarn version --deferred` + `yarn version apply` - For dealing with prereleases, it uses a relatively less-known `stableVersion` field in addition to the `version` field which interacts unintuitively with some workflows. In particular, deferring a semver strategy resolves a named strategy against `version`, which `yarn version apply` applies to `stableVersion` Fixes #3868 Fixes #4014 Fixes #4328 Fixes #5224 Fixes #6810 Fixes #6857 Fixes #6860 Fixes #6970 Fixes #7025 Closes #7110 (supercedes) ## How did you fix it? Reimplemented the `yarn version` and `yarn version apply` commands. Now the bumping logic resides in `yarn version --immediate`. Instead of `yarn version --immediate` being implemented as `yarn version --deferred` + `yarn version apply`, now `yarn version apply` is implemented as `yarn version --immediate decline`. This alleviates the git history requirement of `yarn version --immediate` The prerelease bumping logic is also refactored to be more predictable and can be calculated from a single version, without relying on storing an additional `stableVersion`. Simply put, if the current version is `1.2.0-3`, `prepatch` and `preminor` both bump it to `1.2.0-4` and `premajor` bump it to `2.0.0-0`. `prerelease` is effectively same as `prepatch`. Now that `stableVersion` is not needed, `yarn version --immediate` and `yarn version apply` will remove them from any bumped workspaces. (Our own release pipeline also writes the `stableVersion` field but I don't know if there is a purpose. So I have left them alone for now) The `--prerelease` flag also have some bug fixed. For example, when applying a `prerelease` bump to `1.2.3-alpha.1` with prerelease pattern `beta.%n`, you'd end up with `1.2.3-alpha.1-beta.1`... Also, given how easily "bumping" to a version lower than the current one can happen accidentally due to how prereleases work, there is also now a check to stop that and a `--force` flag to suppress that check. The command documentation has been rewritten and many tests have been added to rigorously document these behavior. ## 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. --------- Co-authored-by: Maël Nison <nison.mael@gmail.com> | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 个月前 | |
Sync master with the changes from master | 1 年前 | |
Sync master with the changes from master | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 3 天前 | ||
| 1 个月前 | ||
| 3 年前 | ||
| 3 个月前 | ||
| 1 年前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 3 天前 | ||
| 3 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 5 个月前 | ||
| 5 个月前 | ||
| 9 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 年前 | ||
| 1 年前 |