chore(deps): raise the fluttersdk_wind floor to 1.5.3 - #154
Conversation
The ceiling was already there: ^1.2.0 admitted 1.5.x, so any app resolving fresh was on it. Moving the floor is what reaches an app that pinned Wind lower, and 1.5.3 is where a focused WAnchor answers ActivateIntent (keyboard, gamepad, TV remote), where one control costs one Tab stop instead of two, and where disabled: reaches a WDiv inside a disabled WAnchor. Magic renders its views through W-widgets, so those were magic's bugs too. The span carries one behavioural break for a pinned consumer: wind 1.4.0 made a single-line WInput default its Return key to TextInputAction.done instead of .next. Magic constructs no WInput of its own, so this reaches consumer forms only; the CHANGELOG entry names the fix.
Both files claimed fluttersdk_wind ^1.1.2 and fluttersdk_artisan ^0.0.8. The real constraints had moved to ^1.2.0 and ^0.0.9 without these following, and the wind bump above moves one of them again.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Note Kodizm (AI-generated). May contain mistakes; verify before acting. A five-file constraint bump that verifies cleanly: the lockfile matches what pub actually resolves, the transitive set is unchanged, and the full suite is green against Wind 1.5.3 - no blocking findings. What I checked rather than assumed:
Minor
TestsNothing in Checks I ran
|
…s for it The Wind floor raise is filed under Changed because magic's own API does not move, and that is still right. But the span crosses wind 1.4.0, which changed what Return does in a multi-field form, and a reader scanning BREAKING for the 0.0.10 upgrade notes would never reach the line telling them to write out textInputAction. BREAKING now carries a pointer with the fix in it.
|
Fixed, and I took the pointer route rather than moving the entry. Your reasoning holds on both sides: the constraint bump belongs under Thanks for the two checks I had not made myself: that Wind 1.5.3 adds no dependency over 1.2.0, which is what makes the 4-line lock diff complete rather than partial, and that 1.5.3 declares the same CI is re-running on the new head. |
|
Note Kodizm (AI-generated). May contain mistakes; verify before acting. Incremental re-review: the only new commit adds the What changed since My earlier findings on the constraint bump itself still stand as verified and unchanged: no TestsNo code changed, so nothing new to cover. My previous run against Wind 1.5.3 ( Checks I ran
|
Moves magic's
fluttersdk_windfloor to 1.5.3, published today.What this actually changes
The ceiling was already there.
^1.2.0admitted 1.5.x, so any app runningflutter pub getwithout a pin was resolving 1.5.3 before this PR and nothing changes for it. What moves is the floor, and the floor is what reaches an app that pinned Wind lower.example/pubspec.lockis the concrete case: it had 1.2.0 locked, and the bump pulls it to 1.5.3 along withfluttersdk_wind_diagnostics_contracts1.0.0 to 1.1.0, both transitive through magic.Why 1.5.3 is worth a floor raise
These are magic's bugs as much as Wind's, because magic renders its views through W-widgets:
WAnchornow answersActivateIntent, so a control reachable by keyboard, gamepad or a television remote actually activates on Enter, Space, the D-pad centre or the Apple TV click.WDivwraps itself in a gesturelessWAnchorwhenever its className carrieshover:,focus:oractive:, and that wrapper used to be a full focus stop, soWAnchor(onTap:) > WDiv('focus:ring-2'), the shape of every ring-styled control, cost two presses of Tab.disabled:now reaches aWDivinside a disabledWAnchor, so an element carryingdisabled:opacity-50stops ignoring its disabled ancestor.The one break in the span, for a pinned consumer
Wind 1.4.0 carries a behavioural break: a single-line
WInputdefaults its Return key toTextInputAction.doneinstead of.next. A multi-field form that relied on Return advancing focus needstextInputAction: TextInputAction.nextwritten out.This reaches consumer forms only. Magic constructs no
WInputof its own; the single hit inlib/is a doc comment invalidates_requests.dart:79. The CHANGELOG entry names the fix so nobody has to find it.Also in here
CLAUDE.md:7and.github/copilot-instructions.md:7both claimedfluttersdk_wind ^1.1.2andfluttersdk_artisan ^0.0.8. The real constraints had already moved to^1.2.0and^0.0.9without those lines following. Corrected in their own commit.Gates
flutter test: 1464 tests, all passed, no skips. Run withpubspec_overrides.yamlmoved aside, so this is against the hostedfluttersdk_wind 1.5.3from pub.dev and not the local path clone.dart analyze lib bin:No issues found!dart analyzeinexample/:No issues found!CI never touchesexample/, so this is the only check that covers the lock change.dart format --output=none --set-exit-if-changed .:Formatted 337 files (0 changed), exit 0.pubspec.yamlis the only real surface:install.yaml, themake:*stubs,example/pubspec.yaml,doc/andskills/carry no Wind version pin.Ordering
#150 (release 0.0.10) is open and waiting. This wants to land first so the release section carries the entry, same as #151 and #148 did.