Skip to content

ci: drop dead depot-ubuntu-latest actionlint config - #1

Merged
jdx merged 1 commit into
mainfrom
ci/remove-depot-actionlint-config
Apr 18, 2026
Merged

jdx merged 1 commit into
mainfrom
ci/remove-depot-actionlint-config

Conversation

@jdx

@jdx jdx commented Apr 18, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • All workflows already run on GitHub-hosted runners (ubuntu-latest, macos-latest, windows-latest) — no job still targets a depot runner.
  • .github/actionlint.yaml existed only to register depot-ubuntu-latest as a valid self-hosted label. With nothing using that label, the file is dead; removing it.

Test plan

  • Confirm grep -r depot comes back empty across the tree.
  • Next workflow run passes without actionlint flagging anything.

🤖 Generated with Claude Code


Note

Low Risk
Removes an unused actionlint configuration entry; impact is limited to CI linting behavior and only if any workflow still referenced the old self-hosted label.

Overview
Removes the .github/actionlint.yaml configuration that declared depot-ubuntu-latest as a valid self-hosted runner label, since it is no longer used anywhere in workflows.

Reviewed by Cursor Bugbot for commit 0217fb4. Bugbot is set up for automated code reviews on this repo. Configure here.

Workflows already run on GitHub-hosted runners (ubuntu-latest,
macos-latest, windows-latest). The self-hosted-runner label was the
only thing in this file, so the whole config is dead.
@greptile-apps

greptile-apps Bot commented Apr 18, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR removes .github/actionlint.yaml, a now-dead configuration file that existed solely to register depot-ubuntu-latest as a valid self-hosted runner label for actionlint. A grep across the repository confirms no workflow files reference depot or depot-ubuntu-latest any longer, so the file's only purpose was suppressing a lint warning for a runner label that is no longer used. The deletion is correct and safe.

  • Deleted .github/actionlint.yaml (3 lines) — no functional code removed, only a stale lint-suppression config.
  • Verified: zero remaining depot references in .github/ across all five workflow files.

Confidence Score: 5/5

Safe to merge — removes only a dead config file with no remaining references anywhere in the repo.

Single-file deletion of a 3-line stale config. No logic, no code, and no remaining depot references in any workflow. The change reduces noise without any risk of regression.

No files require special attention.

Important Files Changed

Filename Overview
.github/actionlint.yaml Deleted dead config file that registered depot-ubuntu-latest as a valid self-hosted runner label; no workflows reference this label, making the file unnecessary.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Workflow push / PR trigger] --> B{Runner label used?}
    B -- "ubuntu-latest / macos-latest / windows-latest" --> C[GitHub-hosted runner]
    B -- "depot-ubuntu-latest (deleted)" --> D[❌ No jobs — label unused]
    D --> E[".github/actionlint.yaml (removed)\nWas suppressing lint warning\nfor this orphaned label"]
    C --> F[CI runs normally]
Loading

Reviews (1): Last reviewed commit: "ci: drop dead depot-ubuntu-latest action..." | Re-trigger Greptile

@jdx
jdx merged commit 949187a into main Apr 18, 2026
4 checks passed
@jdx
jdx deleted the ci/remove-depot-actionlint-config branch April 18, 2026 18:24
jdx added a commit that referenced this pull request Apr 29, 2026
…-alias catalog (#384)

## Summary

Three bug fixes for
[#383](#383) plus
the supporting refactors that fell out of code review.

### Bug fixes

- **Patches against CRLF text files** — tarballs published from Windows
editors ship CRLF (e.g. `gifuct-js@2.1.2/index.d.ts`), but
git/pnpm-style patches always emit LF. Diffy is byte-exact and refused
to match CRLF context against LF hunks, so a clean patch failed with
`error applying hunk #1`. Normalize the original to LF before apply and
restore CRLF on write — same approach pnpm uses. The CRLF restore also
collapses any `\r\r\n` so a patch line containing a literal `\r` byte
mid-line doesn't gain a second carriage return.

- **`aube patch-commit` destination** — previously wrote unconditionally
to `pnpm.patchedDependencies` in `package.json`, even on projects
already using the pnpm v10+ workspace-yaml home. Now follows the unified
rule below. `aube patch-remove` now strips entries from every place they
could live (both yaml and both `pnpm.*` / `aube.*` namespaces) and
reports the actual files rewritten in its status output.

- **npm-aliased catalog deps from pnpm-generated lockfiles**
([discussioncomment](#383 (comment)))
— `aube install --frozen-lockfile` accepted a pnpm lockfile with
`beamcoder: npm:beamcoder-prebuild@…` (declared via
`pnpm-workspace.yaml#catalog`) and silently produced an empty
`node_modules`. The importer's `specifier:` was `'catalog:'`, but the
alias detection only fired on `specifier.starts_with("npm:")`. Now
detects aliases purely from the `version:` shape (the canonical
`<real>@<resolved>` form pnpm always uses), with a peer-suffix strip so
`version: 18.2.0(react@18.2.0)` doesn't get misclassified.

### Refactor: unified workspace-config writer

One rule applies to every command that mutates a setting which can live
in either the workspace yaml or `package.json#{pnpm,aube}.<key>` (`aube
patch-commit`, `aube patch-remove`, `aube approve-builds`, install-time
auto-deny seeding, future settings):

1. If a workspace yaml exists on disk → write there.
2. Otherwise, if `package.json#pnpm` is already declared → write
`pnpm.<key>` (preserve the user's chosen namespace).
3. Otherwise → write `aube.<key>` (aube's native namespace; the read
side already gives `aube.*` precedence over `pnpm.*`).

New helpers in `aube_manifest::workspace`:
- `ConfigWriteTarget` + `config_write_target(dir)` — picks step 1 vs
steps 2/3.
- `edit_workspace_yaml(path, f)` — yaml writer; **skips the rewrite when
the closure produces no structural change**, so user comments survive
every no-op write. Used by allowBuilds, patchedDependencies, and catalog
cleanup.
- `edit_setting_map(cwd, key, f)` — `package.json` writer; picks
namespace per steps 2/3, also skips no-op rewrites.
- `remove_setting_entry(cwd, key, entry_key)` — strips an entry from
both `pnpm.<key>` and `aube.<key>` so a one-namespace removal doesn't
leave a stale duplicate behind on the read merge.

Migrated callers: `aube approve-builds` (and the install-time auto-deny
seed), `aube patch-commit`, `aube patch-remove`, catalog cleanup. The
`PatchDestination` enum and `edit_patched_dependencies` helper that
lived in `aube/src/patches.rs` are gone.

### Refactor: workspace-yaml file selection

Centralized the `aube-workspace.yaml` → `pnpm-workspace.yaml` precedence
walk into `aube_manifest::workspace::workspace_yaml_existing`.
`workspace_yaml_target` is now a one-liner over it. Removed three
duplicates of the same loop (`catalogs.rs`, `find_workspace_root`,
`find_workspace_yaml_root`).

## Test plan

- [x] `cargo test` (1185 passing — new coverage spans CRLF apply +
embedded-`\r` restore in `aube-linker`; helper-level + per-writer
no-op-skip tests for allowBuilds, patchedDependencies, and catalog
cleanup; `ConfigWriteTarget` + namespace-picking cases; pnpm-lockfile
catalog alias)
- [x] `cargo clippy --all-targets -- -D warnings`
- [x] `cargo fmt --check`
- [x] End-to-end repros from the discussion: `aube install` against
`patch-application-failure` succeeds with CRLF preserved; `aube install
--frozen-lockfile` against `catalog-npm-alias` installs `beamcoder`
(resolved to `beamcoder-prebuild`) into `packages/app/node_modules/`

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Touches install/patch/config persistence paths and changes where
settings are written (`workspace` YAML vs `package.json`), which can
affect real projects’ config layout; mitigated by extensive new tests
and largely additive helpers.
> 
> **Overview**
> Fixes patch application on CRLF-backed files by normalizing input to
LF for diff matching and restoring CRLF on write (with protection for
embedded literal `\r`), plus adds regression tests.
> 
> Unifies how workspace-level settings are written: if a workspace yaml
exists, write there; otherwise write to `package.json` under `aube.*`
unless `pnpm` already exists. This refactor is applied to `allowBuilds`
seeding/approval, `patch-commit`/`patch-remove` (including removing
entries from all possible locations and reporting the actual files
changed), and catalog cleanup (now skips no-op YAML rewrites to avoid
stripping comments).
> 
> Fixes pnpm lockfile parsing to detect npm-aliased dependencies based
on the `version:` field shape (including catalog-declared aliases and
peer suffix handling), with new tests.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
74cbd4d. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jdx added a commit that referenced this pull request May 3, 2026
* Skip empty bytes_segment so the phase-2 label doesn't render a
  doubled `·  ·` separator on installs without `dist.unpackedSize`
  (Greptile P1).
* Switch ETA to fetch-window throughput: snapshot completed at the
  set_phase("fetching") boundary, then divide remaining work by
  `fetch_elapsed_ms / (completed - baseline)`. Falls back to `ETA …`
  while the baseline or fetch window are missing. Eliminates the
  pessimistic "110s ETA after a 3s resolve" case (Greptile P2).
* Reconcile estimated_bytes after filter_graph: track per-dep_path
  unpacked_size during streaming, then re-sum surviving dep_paths
  via the new InstallProgress::reconcile_estimated_bytes API.
  Mirrors the package-denominator reconcile applied next to it
  (Greptile P3).
* Apply TARBALL_COMPRESSION_RATIO in TTY refresh_bytes_segment too —
  CI mode applied it; TTY was showing the raw unpacked sum (~3.3×
  inflated) (Cursor #1).
* Refresh ETA on every inc_downloaded_bytes so it doesn't freeze
  during long downloads when no inc_total / inc_reused events fire.
  Documents the trade-off at FetchRow::drop where a refresh would
  require a larger refactor (Cursor #3).
* Style only the ✓ green on the install / no-op summaries instead
  of the whole sentence; aligns with the CI heartbeat summary's
  styling so the success cue stays sharp without bleeding green
  across the line (Cursor #4 + user request).
* Standardize the ✓ prefix on both Already-up-to-date paths
  (`print_install_summary` and `print_already_up_to_date`).

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jdx added a commit that referenced this pull request May 11, 2026
#612)

## Summary
- Adds optional BOLT phase 4 to `benchmarks/pgo.bash` (gated on
`AUBE_PGO_BOLT=1`)
- Enables it for `x86_64-unknown-linux-gnu` and
`aarch64-unknown-linux-gnu` PGO targets in `release.yml`
- Uses BOLT's **instrumentation mode** (no `perf`, no LBR/BRBE), so the
same flow works on x86_64 and aarch64
- Installs `bolt-18` from `apt.llvm.org` (Ubuntu noble's archive package
is amd64-only)

## What BOLT does on top of PGO
PGO drives LLVM's instruction-level codegen (inlining, branch weights,
function granularity). BOLT rewrites the linked binary to do post-link
block layout (`ext-tsp`), function reordering (`cdsort`), and hot/cold
splitting LLVM can't see at IR time. They optimize different layers, so
stacking is additive.

## Why instrumentation rather than perf-LBR
Instrumentation mode (this PR) injects counters into the binary, the
instrumented binary writes one fdata file per process, and `merge-fdata`
rolls them up. The `perf record + perf2bolt` flow was tried first and
failed in CI because (1) Namespace runners default to
`kernel.perf_event_paranoid=2` and ignore `sudo sysctl -w` from workflow
steps, denying LBR branch sampling; and (2) aarch64 hosts can't use
Intel LBR at all.

Side effect of instrumentation: richer profile. Local measurement shows
**3415 functions profiled (16.3%)** vs 1261 (6.0%) with LBR. The dry-run
(25688552218) confirmed identical numbers on both archs in CI:
x86_64-gnu 3379 functions (16.2%) / 1784 reordered, aarch64-gnu 3382
(16.4%) / 1701 reordered.

## Measurement
Local Zen 4 (Ryzen 9 7950X3D), n=20 `perf stat` runs of `aube install`
on an already-installed project (pure user-mode work). PGO vs PGO+BOLT:

| counter | PGO | PGO+BOLT | Δ |
|---|---|---|---|
| wall | 8.112 ± 0.122 ms | 7.890 ± 0.094 ms | **-2.74% (z=-6.45)** |
| cycles:u | 8.54M ± 1.53% | 8.38M ± 1.41% | -1.82% (z=-3.94) |
| branch-misses:u | 64,993 | 62,115 | -4.4% |
| L1-icache-load-misses | 25,677 | 21,061 | **-18.0%** |
| iTLB-load-misses | 9,434 | 9,306 | -1.4% |

## What this doesn't move
The canonical hyperfine install benchmarks (gvs-warm, ci-warm, ci-cold)
— both the existing fixture and the vlt-benchmarks large fixture (109
direct deps, 1410 transitive) — **do not move statistically**. All
deltas within combined σ, |t| < 1.5. Real installs spend ~80% of wall
time in system calls; BOLT only affects user-mode codegen, and the gains
get buried under syscall jitter.

## Pipeline cost
- `pgo.bash` grows ~100 lines (new phase 4 + helper refactor);
shellcheck clean
- `release.yml` grows ~25 lines (toolchain install step + matrix `bolt`
flag)
- Extra ~1–2 min per affected target on release (build instrumented
binary + replay training + merge + rewrite)
- Final binary roughly same size (BOLT split-cold section vs strip — net
wash after `strip = "debuginfo"`)
- New apt source: `apt.llvm.org/<codename>/ llvm-toolchain-<codename>-18
main`; new build dep `bolt-18`

## What's not in this PR
- **`x86_64-unknown-linux-musl`** — BOLT's instrumentation runtime
(`libbolt_rt_instr.a`) is built against glibc and pre-main SIGSEGVs at
startup under musl's static libc (init_array / `_exit` / TLS semantics
differ). Confirmed empirically in dry-run 25688552218. The musl target's
audience cares about static binaries, where instrumenting at link time
is invasive anyway; revisit if/when LLVM upstream ships a
musl-compatible BOLT runtime.
- `aarch64-apple-darwin` — BOLT macOS support isn't in upstream LLVM
yet.
- Larger CI training fixture — out of scope; PGO + BOLT train on the
same bench fixture as today.

## Test plan
- [x] Local: `AUBE_PGO_BOLT=1 bash benchmarks/pgo.bash` produces a
working binary, verified `aube --version` and `aube --help`
- [x] `actionlint` + `shellcheck` + `cargo fmt --check` + `cargo clippy
--all-targets -- -D warnings` clean
- [x] CI dry-run #1 (25686331454): identified the perf-LBR failure
modes, pivoted to instrumentation
- [x] CI dry-run #2 (25688552218): **x86_64-gnu ✓, aarch64-gnu ✓**, musl
excluded based on this run's failure

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes the release build pipeline and produced binaries by adding a
new BOLT rewrite phase and new apt.llvm.org dependency, which could
affect build reliability and artifact correctness on Linux PGO targets.
> 
> **Overview**
> Adds an **optional BOLT “phase 4”** to `benchmarks/pgo.bash` (gated by
`AUBE_PGO_BOLT=1`) that relinks the PGO-optimized binary with
`--emit-relocs`, instruments it with `llvm-bolt`, replays the existing
training workload to collect/merge `fdata`, then rewrites the final
binary with block/function reordering and hot/cold splitting.
> 
> Updates the `release.yml` PGO matrix with a per-target `bolt` flag,
installs `bolt-18` from `apt.llvm.org` when enabled, and turns BOLT on
for `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` while
explicitly keeping it off for musl and macOS rows.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
83f0b51. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jdx added a commit that referenced this pull request Sep 30, 2026
)

<!-- entire-trail-link-start -->
https://entire.io/gh/aubepkg/aube/trails/105
<!-- entire-trail-link-end -->

Patches written by `pnpm patch-commit` often leave the file's
unterminated last line as context without a `\ No newline at end of
file` marker. aube already tolerates that (#1515), but the tolerance
silently failed for any hunk with a git section heading after the second
`@@`, such as `@@ -2,4 +2,4 @@ module.exports = 1;`. Git writes a
heading for most hunks that don't start at line 1, so real patches hit
this often. Install failed with `error applying hunk #1`.

The retry re-rendered the parsed patch with diffy's `Display`, which
writes a heading back with an extra space and an extra blank line. The
blank line re-parses as an empty context line, so the hunk could no
longer match.

The retry now writes the `@@ -a,b +c,d @@` headers itself, without the
heading, then the hunk lines and the EOF marker. Matching is still
exact, so content mismatches are still rejected and patches that
explicitly change the trailing newline keep their meaning.

Before, with a patch like:

```diff
@@ -2,4 +2,4 @@ module.exports = 1;
 module.exports = 1;
-b
+B
 c
 end
```

against a file whose last line `end` has no trailing newline, install
failed. Now it applies, and the unterminated last line is preserved.

Validation: added
`missing_eof_context_marker_supports_hunk_section_headings`; the
`aube-linker` patch tests pass. I did not run the reporter's repro
repository.

Fixes discussion #1676

*AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5;
version: unavailable.*

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Patches containing a hunk section heading and an unterminated final
context line now apply correctly. The heading remains unchanged when the
patch includes context that reaches the end of the file, improving
reliability for this case. This fix applies to patches where the final
context line has no trailing newline.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
jdx added a commit that referenced this pull request Oct 20, 2026
aube-written `pnpm-lock.yaml` files order a package's peer suffix
differently from pnpm 11, so tools that regenerate the lockfile with
pnpm (e.g. Dependabot) rewrite lines that did not really change. This is
difference #1 of discussion
#1779.

pnpm sorts the peer suffix by the full `name@version(...)` string, so
`react-dom@…` comes before `react@…` (`-` sorts before `@`). aube sorted
by peer name only.

Before:

```
'@testing-library/react@14.0.0(react@18.2.0)(react-dom@18.2.0(react@18.2.0))'
```

After (same as pnpm 11.27.1 for this package, apart from optional peers,
which are a separate follow-up):

```
'@testing-library/react@14.0.0(react-dom@18.2.0(react@18.2.0))(react@18.2.0)'
```

The issue's example
`4.7.0(monaco-editor@0.57.0)(react-dom@19.3.0(react@19.3.0))(react@19.3.0)`
is now covered by a unit test.

## Migration

Existing aube-written lockfiles that contain a package with both a
`react` and a `react-dom`-style peer pair (any suffix where a name is a
`-`-prefixed extension of another) shift once on the next resolve. Only
the key order changes. Lockfiles read as-is: keys are not re-sorted on
read, so a frozen install of an old-order lockfile keeps working, and
pnpm accepts either order.

## Scope

Only the dep_path suffix order changes (the per-package suffix and the
cumulative suffix rewrite). Scope propagation and the fixed-point loop
are unchanged.

## Validation

- Checked the ordering against `pnpm@11.27.1 install --lockfile-only` on
`react` + `react-dom` + `@testing-library/react@14.0.0`.
- `cargo test`, `cargo clippy --all-targets -- -D warnings`, `cargo fmt`
pass; new test `suffix_orders_peers_by_full_name_at_version_string`.
- Updated the bats test expecting the old order and ran
`peer_deps.bats`, `peers.bats` and `pnpm_monorepo_dedupePeers.bats`.

*AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5;
version: unavailable.*

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
jdx added a commit that referenced this pull request Oct 20, 2026
aube-written `pnpm-lock.yaml` files leave out optional peers that pnpm
11 resolves, so Dependabot (which runs pnpm) rewrites snapshot keys it
did not need to touch. This is difference #2 of discussion
#1779. Difference #1 (suffix
order) is in #1792 and #3 (unused
catalog entries) in #1788.

I ran `pnpm@11.27.1 install --lockfile-only` on small fixtures to
establish the rules, and the aube output now matches pnpm's `snapshots:`
byte for byte on all of them (and on the importer rows):

1. **Optional peers resolve from anywhere in the graph (when
`dedupePeerDependents` is on, the default).** If a satisfying version is
already resolved anywhere in the workspace, even in an unrelated
importer's subtree, pnpm binds it. With `autoInstallPeers: false`,
`vite@7.1.0` in one importer gets `(jiti@2.7.0)` when only another
importer's `c12` pulls in jiti. aube only looked at ancestors, the
package's own deps and the workspace root. This also covers debug's
`supports-color`, which pnpm 11 binds when `chalk` brings it in.
2. **A resolved optional peer is listed under `optionalDependencies:`**
in the snapshot, not `dependencies:`.
3. **Compatible variants of the same package merge across importers.**
Importer `a` resolving vite with `jiti` and importer `b` with `yaml`
both end up as `vite@7.1.0(jiti@2.5.1)(yaml@2.8.1)`. Variants whose
peers conflict (different `jiti` versions) stay separate.

Before (importer `apps/web` and `apps/other` share vite, only `web` has
jiti and yaml):

```
apps/other: vite 7.1.0(@types/node@24.3.0)(tsx@4.20.5)
apps/web:   vite 7.1.0(@types/node@24.3.0)(jiti@2.5.1)(tsx@4.20.5)(yaml@2.8.1)
```

After (same as pnpm 11):

```
apps/other: vite 7.1.0(@types/node@24.3.0)(jiti@2.5.1)(tsx@4.20.5)(yaml@2.8.1)
apps/web:   vite 7.1.0(@types/node@24.3.0)(jiti@2.5.1)(tsx@4.20.5)(yaml@2.8.1)
```

With `dedupePeerDependents: false` pnpm 11 leaves those peers
unresolved, and so does aube.

## Migration

Existing aube-written lockfiles shift once on the next resolve for any
package whose optional peers are now resolved. Lockfiles are read as-is,
so frozen installs of old lockfiles keep working.

## Not covered yet

Running both tools fresh on the repro repo (speakeasy-api/gram at
e537882348) still leaves differences. They come from optional peers a
package gets only because a *descendant* needs them, e.g.
`@ai-sdk/react@4.0.138(react@19.3.0)(zod@4.6.7)`, where `zod` is only a
peer of its child `@ai-sdk/mcp`, and
`@testing-library/react@14.0.0(@types/react@…)`. pnpm hoists those
resolved optional peers into the importer's scope so every package below
sees them; aube's ancestor-propagation gate does not. I did not change
that because I could not pin the rule down from output alone without
risking regressions. This is a follow-up.

## Validation

- Compared `snapshots:` against `pnpm@11.27.1` on fixtures covering:
optional peer provided by another importer's subtree, by the root, by a
cousin dep, version conflicts across importers, three importers with
partial overlap, dedupePeerDependents off, and required peers across
importers (already matching).
- The old unit test `optional_peer_is_not_bound_via_graph_scan` asserted
the opposite of pnpm 11's behavior (which I checked: pnpm 11.27.1 binds
`supports-color@7.2.0` for `debug` when `chalk@4` is in the graph). It
is replaced by tests for the new behavior, plus a variant-merge test.
- `cargo test`, `cargo clippy --all-targets -- -D warnings`, `cargo
fmt`; bats `peer_deps`, `peers`, `install`, `update`, `prune`,
`optional_platform`, `pnpm_monorepo_dedupePeers`.

*AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5;
version: unavailable.*

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved optional peer dependency resolution across the dependency
graph when deduplication is enabled.
* Compatible optional peers are now consolidated across variants, while
conflicting versions remain separate.
* Resolved optional peers are recorded correctly, and unresolved peers
continue to be reported when no satisfying version is available.
  * Clarified peer dependency resolution behavior in relevant output.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant