Repository navigation
deps(npm): bump typescript from 5.9.3 to 7.0.2 in /tests/stress_perf_rn/VirtualList - #1250
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.9.3 to 7.0.2. - [Release notes](https://github.com/microsoft/TypeScript/releases) - [Commits](microsoft/TypeScript@v5.9.3...v7.0.2) --- updated-dependencies: - dependency-name: typescript dependency-version: 7.0.2 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
📦 Build metricsArtifact sizes for Packages (compressed .nupkg)
Assemblies in Microsoft.UI.Reactor
Assemblies in Microsoft.UI.Reactor.Advanced
Assemblies in Microsoft.UI.Reactor.Devtools
No size change beyond the noise floor. ✅ ✅ smaller / |
🧪 Merged coverageCoverage for
No coverage change beyond the noise floor. ✅ ✅ higher / |
…tory (#1252) * deps: group Dependabot majors by package family, not one PR per directory #1244 grouped routine minor/patch updates into a single PR, which worked -- the next run collapsed 29 of its 37 pending updates into one PR (#1245). But majors were deliberately left ungrouped, and Dependabot reads "ungrouped" as one PR per package *per directory*. Adopting TypeScript 7 therefore arrived as four identical PRs (#1246, #1247, #1250, #1251) for a single decision, and jest 30 as two more (#1248, #1249). "Majors get their own PR" was meant per breaking change, not per directory. Majors are now grouped by package family -- typescript, jest, react, @react-native-community/cli, prettier -- so one breaking change is one PR spanning every directory it touches, and two unrelated breaking changes still never share a diff. The families are the ones that genuinely move together, the same rule the nuget entry already applies to the roslyn groups. Verified rather than assumed. A simulator for Dependabot's group resolution (patterns/update-types/ignore, first match wins, grouped PRs span directories) was run against the 37 real pending updates scraped from #1245-#1251: old config -> 9 PRs, new config -> 3 PRs As a control the same simulator was run against the pre-change config on main, where it predicts 9 against the 7 Dependabot actually opened -- the difference is entirely Dependabot bundling a package with its @types (jest + @types/jest in two directories = 2 PRs, not 4), which the simulator does not model. The new config produces no ungrouped PRs at all, so that nuance cannot alter the 3. Separately, this holds @rnx-kit/jest-preset, which the simulation surfaced as mis-sorted. It is required directly by both harnesses' jest.config.windows.js, and 0.3.3 adds `peer @react-native/jest-preset: ">=0.85"` where 0.1.x declared no such peer -- a react-native 0.85 generation package, while these harnesses pin react-native at 0.82.x and are blocked from moving. Being a 0.x package, that arrives as a *minor*, so it was sitting inside the routine batch in #1245. Measured: `npm install` resolves 0.3.3 and silently omits the unsatisfiable peer from the tree rather than failing, which is why it is suppressed here instead of left to surface downstream. No code or lockfile changes; this only affects what Dependabot opens next run. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 504b5020-f687-4a59-9212-aa2c90c4b7ec * deps: sort @rnx-kit/jest-preset by its real (0.x minor) breaking axis Copilot review on #1252. The `jest-major` group listed @rnx-kit/jest-preset but is scoped to `update-types: [major]`, and that package is 0.x -- its breaking axis is semver-MINOR. So the listing was inert: once the react-native upgrade lifts the ignore, a breaking 0.3 -> 0.4 would have matched the earlier catch-all `npm-minor-patch` group instead, which is precisely how the incompatible 0.1 -> 0.3 bump reached #1245 in the first place. Given it its own group, `update-types: [minor, major]`, placed before npm-minor-patch so first-match-wins sorts it there, and removed it from jest-major where it could never have matched. Verified with the group simulator in two scenarios: - today (ignore active): unchanged, still 3 PRs for the 37 pending updates - ignore lifted, synthetic 0.3.3 -> 0.4.0: lands in rnx-kit-jest-preset-breaking, while a routine jest 30.5.1 -> 30.5.2 patch still batches into npm-minor-patch Config comments only; no behaviour change while the ignore stands. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 504b5020-f687-4a59-9212-aa2c90c4b7ec --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 504b5020-f687-4a59-9212-aa2c90c4b7ec
|
Closing in favour of a regrouped run. TypeScript 5.x → 7.0.2 is a major, and majors were previously ungrouped — which Dependabot fans out as one PR per package per directory. That produced four identical PRs (#1246, #1247, #1250, #1251) for a single decision. #1252 (merged) adds a |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
Bumps typescript from 5.9.3 to 7.0.2.
Release notes
Sourced from typescript's releases.
Commits
1e4744dMerge branch 'main' into ts7-releasea5a219cmicrosoft/typescript-go#4558ecfe30dUpdate status localization5de25b5Hide executable name in TypeScript statusd7ce74aShow bundled TypeScript version for packaged servers29be66aCorrect TS 7 release version to 7.0.2ed2bd1bMerge branch 'main' into ts7-release8873075Bump the github-actions group across 1 directory with 3 updates (microsoft/ty...9427131Set up stable / nightly extension split, other prep (microsoft/typescript-go#...d4eaca5microsoft/typescript-go#4549Maintainer changes
This version was pushed to npm by microsoft1es, a new releaser for typescript since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)