chore(repo): migrate to material_ui and cupertino_ui - #2896
Draft
xsahil03x wants to merge 3 commits into
Draft
Conversation
Flutter split Material and Cupertino out of the framework into the flutter.dev-published `material_ui` / `cupertino_ui` packages (both v1.0.0, 2026-08-12, the same day as Flutter 3.47 stable). Both require `flutter: >=3.44.0`, which is exactly the floor raised in the parent commit — that is what unblocks this work, and why it is stacked. Rewrites all 409 import directives across 405 tracked files: `package:flutter/material.dart` -> `package:material_ui/material_ui.dart` (403) and `package:flutter/cupertino.dart` -> `package:cupertino_ui/cupertino_ui.dart` (6). Only the URI is replaced, so the three imports carrying `show`/`hide` clauses keep them. Every occurrence was verified to be a plain import directive first: no export directives and no doc/string references to either URI exist in the repo. The migration is done by hand rather than by the README's `dart fix --apply --code=migrate_design_widgets`. That fix is staged in the SDK's `fix_data/fix_material/fix_material.yaml` but inert here: it is a data-driven `replacedBy` keyed off the library being deprecated, and `package:flutter/material.dart` carries no `@Deprecated` annotation in 3.47 yet (the transform's own TODO reads "Link eventual deprecation PR"). `dart fix` reports "Nothing to fix!" against the real packages. The rewrite reproduces that fix's output exactly, confirmed against a probe package where it does apply. Reordering the imports moved them relative to their neighbours, so `directives_ordering` is reapplied via `dart fix` (188 files). Localizations follow step 2 of the migration guide: `GlobalMaterialLocalizations` now comes from `material_ui` and `GlobalCupertinoLocalizations` from `cupertino_ui`, while `GlobalWidgetsLocalizations` stays in `flutter_localizations`, which is still its home. The `flutter_localizations` import is narrowed with a `show` so its own `GlobalMaterialLocalizations` cannot collide with material_ui's. The public barrel re-exports each from its new home. BLOCKED, and not mergeable as-is: 19 type errors remain, all of them the two type universes failing to meet. `material_ui` ships its own implementations and Flutter 3.47's `material.dart` does not re-export them, so `flutter/material`'s `ThemeData`/`ThemeExtension`/`ColorScheme` are unrelated types to `material_ui`'s. 18 come from `stream_core_flutter`, whose `StreamTheme extends ThemeExtension<StreamTheme>` still binds Flutter's `ThemeExtension`; 1 from `dynamic_color`, whose `DynamicColorBuilder` takes Flutter's `ColorScheme`. Both dependencies must migrate before this can land. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
`command.bootstrap.dependencies` is the workspace's single version registry — every shared dependency is pinned there, not only in the pubspecs that use it. The previous commit added both packages to the 14 pubspec entries but skipped the registry, leaving their versions unmanaged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Without the lint nothing stops a new file importing package:flutter/material.dart, silently reintroducing the split between Flutter's Material types and material_ui's. Enabling it is safe at the 3.44 floor even though that analyzer does not recognise the rule. `undefined_lint` is reported against analysis_options.yaml itself, so it only surfaces when that file is inside the analysed directory. legacy_version_analyze runs `cd packages/X/lib && dart analyze --fatal-infos .`, which leaves the options file out of scope: verified exit 0 from lib/ versus exit 2 from the package root with the same unknown rule enabled. The main analyze job runs the latest stable, which knows the rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Submit a pull request
Linear: FLU-696
CLA
Description of the pull request
Flutter has split Material and Cupertino out of the framework into the flutter.dev-published
material_uiandcupertino_uipackages — both v1.0.0, published 2026-08-12, the same day as Flutter 3.47 stable.Both require
flutter: >=3.44.0. That is exactly the floor #2894 raises, which is what makes this work possible now and why it is stacked rather than standalone.What changed
package:flutter/material.dart→package:material_ui/material_ui.dart(403) andpackage:flutter/cupertino.dart→package:cupertino_ui/cupertino_ui.dart(6). Only the URI is replaced, so the three imports carryingshow/hideclauses keep them. Verified up front that every occurrence is a plainimportdirective — there are noexportdirectives and no doc/string references to either URI anywhere in the repo.material_ui×10,cupertino_ui×4), and both registered inmelos.yaml'scommand.bootstrap.dependencies— the workspace's single version registry, where every shared dependency is pinned.directives_orderingreapplied viadart fix(188 files). Renaming the URIs moved them relative to their neighbours; the lint is enabled repo-wide, so this is a consequence of the rewrite, not unrelated churn.GlobalMaterialLocalizationsnow comes frommaterial_uiandGlobalCupertinoLocalizationsfromcupertino_ui;GlobalWidgetsLocalizationsstays influtter_localizations, which is still its home. Theflutter_localizationsimport is narrowed with ashowso its ownGlobalMaterialLocalizationscan't collide with material_ui's. The public barrel re-exports each from its new home — this is a public API change forstream_chat_localizations.Why the migration is hand-rolled, not
dart fixThe README says to run
dart fix --apply --code=migrate_design_widgets. That does not work in Flutter 3.47. The transform ships in the SDK atfix_data/fix_material/fix_material.yaml, but it is a data-drivenreplacedBykeyed off the library being deprecated — andpackage:flutter/material.dartcarries no@Deprecatedannotation in 3.47. The transform's own comment readsTODO(Piinks): Link eventual deprecation PR. Against the real packagesdart fixreportsNothing to fix!even with the lint enabled and the diagnostic firing 13×.The rewrite reproduces that fix's output byte-for-byte, confirmed against a probe package where the fix does apply.
Why it's blocked
material_uiships its own implementations, and Flutter 3.47'smaterial.dartdoes not re-export them. Soflutter/material'sThemeData/ThemeExtension/ColorSchemeandmaterial_ui's are unrelated types. Reproduced minimally:The 19 remaining errors are all that collision, from two dependencies that haven't migrated:
stream_core_flutterStreamTheme extends ThemeExtension<StreamTheme>still binds Flutter'sThemeExtensiondynamic_colorDynamicColorBuilder's builder takes Flutter'sColorSchemestream_core_fluttermust migrate first — it's ours, so that's a sequencing decision, not a wait.dynamic_coloris third-party and only affectssample_app.MaterialUiCompatibilityBridgedoes not rescue this. It is documented as an app-level tool for a modern app hosting legacy widgets; it bridgesThemeData/MaterialLocalizationsat runtime and does nothing for compile-time signature mismatches, nor for the reverse case of a legacy app hosting a migrated SDK.Consumer impact
For the same reason, this is breaking for every consumer of
stream_chat_flutter: once our public API speaks material_ui types, an app still onpackage:flutter/material.dartgets the error above, andTheme.of(context)lookups won't resolve across the two universes at runtime. This needs a major version and coordination with the other Stream SDKs.Testing
dart analyze --fatal-infos@ 3.44.0 floordart format, 1004 tracked filesstream_chat_flutter_corestream_chat_persistencestream_chat_localizationsstream_chat.dart:209stream_chat_flutterGoldens were not run or regenerated: the package doesn't compile until the blocker clears, and
material_ui's widgets may rasterise differently, so the ~40-golden macOS baseline from #2894 needs re-checking once it does.Follow-up
migrate_design_widgetsis deliberately not enabled inanalysis_options.yaml. The 3.44 floor analyzer doesn't recognise the rule and exits 2 on unknown names, which would faillegacy_version_analyze. It becomes adoptable when the floor reaches 3.47.Screenshots / Videos
Not applicable — no intended visual change. Any pixel movement from
material_ui's implementations is a finding, not an expectation.🤖 Generated with Claude Code