Decoupling Material and Cupertino

[justinmc]

Superseded by #11669

This is a single super mega PR attempting to migrate all Material and Cupertino code from flutter/flutter to material_ui and cupertino_ui.

To create this PR I used:

git filter-repo --path packages/flutter/lib/src/material --path packages/flutter/test/material --path examples/api/lib/material --path examples/api/test/material --path packages/flutter/lib/src/cupertino --path packages/flutter/test/cupertino --path examples/api/lib/cupertino --path examples/api/test/cupertino 
cd ../packages
git remote add source-origin ../flutter
git fetch source-origin
git merge source-origin/master --allow-unrelated-histories

For both Material and Cupertino, I'm importing:

• The main source code (packages/flutter/lib/src/<material/cupertino>).
• The widget/unit tests (packages/flutter/test/<material/cupertino>).
• The examples (examples/api/lib/<material/cupertino>).
• The example tests (examples/api/test/<material/cupertino>).

TODOs

• Do exports for Material and Cupertino.
• Confirm the directory structure (current plan: lib/src/ for now, reorganize after 1.0.0).
• Try installing and using the packages locally.
• Try running the tests locally (works except for tests with cross imports).
• Try running the example tests locally (work after migrating package:flutter_api_samples import).
• Verify examples work.
• Verify that git blame appears the same in both repos on various files. (Yes, but the SHAs are different, as expected.)
• Port imports of material/cupertino in places like examples/test to use the new packages.
• Fix all test cross imports, or decide to merge this without them and fix later. Can these fixes be ported afterwards? The problem of partial commit SHAs shouldn't apply to these new things.

Open questions

• Are we sure about the directory structure?
  • What happens when a user imports material_ui.dart and there are things with the same name in both m3 and m3e?
• Anything else that should be ported along with this? If these commits touch files that are not included in this PR, but that we later port in, the commits will likely have different SHAs.
• Do we like the examples setup? Separate package at material_ui_examples that points to material_ui via the pubspec workspace. Similar to how flutter/flutter's flutter_api_samples works.

How to try using these packages

Add the local packages to your project:

flutter pub add cupertino_ui --path ../../packages/packages/cupertino_ui
flutter pub add material_ui --path ../../packages/packages/material_ui  

Then import the packages instead of the libraries in the SDK:

- import 'package:flutter/material.dart';
- import 'package:flutter/cupertino.dart';
+ import 'package:material_ui/material_ui.dart';
+ import 'package:cupertino_ui/cupertino_ui.dart';

Resources

• Closed PR where I tried and failed to import a single widget by individually importing all of its transitive dependencies with git filter-repo commands.
  • Decoupling Material's ProgressIndicator #11526
• Closed PR where I tried to import just colors.dart (no dependencies), but found that it would create different SHAs between it and this mega PR.
  • Decoupling Material's colors.dart #11543
• Close PR where I tried to import all of Material, before realizing that I would create different SHAs between that PR and a future Cupertino PR.
  • Decoupling Material #11549

[justinmc]

@dkwingsmt @QuncCccccc Currently I've copied all of the code in lib/src/ for both material_ui and cupertino_ui. Instead should I be setting up for your plans and creating cupertino18 and m3 directories? Or maybe should that come in a subsequent PR before or after 1.0.0?

[dkwingsmt]

The file structure for cupertino_ui is still under discussion, which I'm working on. So let's put off the Cupertino part later.

[justinmc]

Sounds good. I guess messing with the directory structure at this point could even break some people. Possibly something for v2.0.0.

[dkwingsmt]

Sorry, I probably didn't make it clear. I'm hoping to place the cupertino code into a place that is consistent from v1.0.0 and onwards, but I'm still unsure where that would be. I'll draw a conclusion in the near future, so I suggest putting off this PR (for the cupertino part) until we've made up our mind.

[QuncCccccc]

should I be setting up for your plans and creating cupertino18 and m3 directories?

I tried to migrate IconButton this week by creating a m3 folder to put the current IconButton and creating a m3e folder to add a new icon_button.dart, but moving current icon_button.dart to /m3 will also cause compilation errors because all the import path need to update and files which imports lib/src/icon_button.dart will also need to update. So I think no need to create an extra m3 folder to introduce unnecessary work. But I'm still planning to create a /m3e for m3e widgets.

[justinmc]

Closing in favor of #11669. This PR did not include the history of dart fixes and their tests.