Repository navigation
fix(config): deprecate experimental monorepo root key - #11052
Conversation
|
Warning Review limit reached
Next review available in: 33 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesLegacy monorepo root support
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR deprecates the
Confidence Score: 5/5The change is safe to merge; it replaces a serde alias with an explicit field and a trivially correct migration step, with no behavioral change for configs that already use monorepo_root. The core migration logic (get_or_insert, take, deprecated_at!) is correct for all combinations of old/new key presence. The only issues are a date mismatch between the PR description and the remove_at argument, and a stale comment in the e2e test. The remove_at date discrepancy in src/config/config_file/mise_toml.rs is the only item worth a second look before merge. Important Files Changed
Reviews (3): Last reviewed commit: "fix(config): extend experimental key rem..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…ver published The `monorepo_root` key first landed in the 2026.7.9 tag (jdx/mise#11052), but 2026.7.8, 2026.7.9, and 2026.7.10 were tagged and never published to the release/install channels (release-pipeline issue); their changes shipped in 2026.7.11 (published 2026-07-20). Pinning the floor to a version nobody can `mise use`/install would just trade a warning for an unsatisfiable requirement, so raise it to 2026.7.11 — the first *installable* release that recognizes `monorepo_root`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…t key (aws-samples#888) * fix(tooling): bump mise min_version to 2026.7.9 for the monorepo_root key PR aws-samples#874 renamed `experimental_monorepo_root` -> `monorepo_root`, but that key did not exist until mise 2026.7.9 (jdx/mise#11052, 2026-07-16). Any contributor on `2026.2.6 <= mise < 2026.7.9` therefore got a per-prompt `unknown field: monorepo_root` warning. Raise the floor to match the config the repo actually requires, turning a silent warning into a clear upgrade gate. Closes aws-samples#887 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(tooling): raise child mise.toml floors to 2026.7.9 for consistency The four workspace configs (cdk/agent/cli/docs) declare the same `min_version` floor as the root and are meant to move together. Keep all five uniform at 2026.7.9 so the monorepo presents one coherent floor. Refs aws-samples#887 * fix(tooling): correct floor to 2026.7.11 — 2026.7.8–2026.7.10 were never published The `monorepo_root` key first landed in the 2026.7.9 tag (jdx/mise#11052), but 2026.7.8, 2026.7.9, and 2026.7.10 were tagged and never published to the release/install channels (release-pipeline issue); their changes shipped in 2026.7.11 (published 2026-07-20). Pinning the floor to a version nobody can `mise use`/install would just trade a warning for an unsatisfiable requirement, so raise it to 2026.7.11 — the first *installable* release that recognizes `monorepo_root`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: scottschreckengaust <345885+scottschreckengaust@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: ayushtr-aws <ayushtr@amazon.com>
Summary
experimental_monorepo_rootimmediately and schedule removal for 2027.12.0monorepo_rootduring deserializationWhy
Monorepo support graduated from experimental in June 2026, but the old configuration key remained a silent compatibility alias. Since the old key was explicitly experimental, it can begin warning immediately while retaining compatibility until December 2027.
Review notes
Deprecation warnings intentionally deduplicate globally by deprecation ID. The warning signals that the legacy key must be migrated; it is not intended to enumerate every config file containing it. Emitting it once also avoids warning spam when mise loads many config files.
Performance
This does not parse TOML a second time. It adds one optional boolean field and normalizes it during the existing config deserialization path, so canonical configurations have only a negligible branch at load time and no recurring runtime cost.
Validation
mise run lint-fixmise run test:e2e e2e/tasks/test_task_monorepo_validationgit diff --checkSummary by CodeRabbit
experimental_monorepo_root.experimental_monorepo_rootis detected, the system now shows a deprecation notice.monorepo_rootis not set, the legacy value is migrated intomonorepo_rootwithout overriding any explicitly configured setting.