Hameed Habeeblahi

Posted on May 1

I Got 4 PRs Merged to the Flutter Framework. Here's Exactly How

#flutter #beginners #opensource #github

I Got 4 PRs Merged to the Flutter Framework. Here's Exactly How

I never thought I'd contribute to a framework used by millions of developers.

Flutter felt like this massive codebase maintained by Google engineers, way out of my league. But three months ago, I decided to try anyway. Today, I have 4 pull requests merged into the official Flutter repository (flutter/flutter), reviewed and approved by the Flutter team at Google.

Here is exactly how I did it, step by step.

Why I Wanted to Contribute

I have been building Flutter apps for over 5 years across fintech, e-commerce, IoT, real estate, and healthcare products. I use Flutter every single day. But I had never looked under the hood.

Three things pushed me to finally try:

I wanted to understand how Flutter actually works at the framework level, not just how to use it. I wanted to give back to a tool that has been central to my entire career. And I wanted to stand out as a developer, because very few Flutter developers ever contribute back to the framework itself.

So I went looking for a way in.

Step 1: Finding the Right Issue

I went to the Flutter GitHub repository and started filtering issues. The key is not to look for something impressive on your first try. You are looking for something clearly defined, well-scoped, and achievable without deep internal knowledge of the codebase.

I found Issue #177414, a cleanup task to remove cross-imports from widget test files. Specifically, many test files in the widgets package were importing from Material or Cupertino packages when they should only be importing from the core widgets or flutter_test packages. This created unnecessary coupling between layers of the framework.

It was a perfect entry point because the problem was clearly described, the fix pattern was consistent across multiple files, and each file could be a separate PR, meaning one issue could generate several contributions.

Tip: Look for labels like "good first issue", "a: accessibility", or "cleanup". Avoid anything marked "severe" or "P0" until you know the codebase well.

Step 2: Understanding the Codebase Before Touching It

Before writing a single line of code, I did the following:

I read the CONTRIBUTING.md file in full. Every open source project has different rules about branch naming, commit messages, PR descriptions, and test requirements. Flutter's is thorough and worth reading carefully.

I forked the repository and set up Flutter from source locally. This is different from installing Flutter normally. You are cloning the engine and framework, not just downloading a binary.

I found the specific test files mentioned in the issue and read them to understand what "correct" looked like versus what needed fixing.

The problem in these files was that widget tests were using MaterialApp or CupertinoApp as their test wrapper, which pulled in the entire Material or Cupertino layer unnecessarily. The correct approach was to use framework-level wrappers that do not carry that dependency.

Step 3: Making the First Fix

I started with autofill_group_test.dart for PR #181903.

The change sounds simple, and technically it is. But getting it right requires understanding why the dependency exists in the first place and what the correct replacement is. Reviewers will reject a change that fixes the import but breaks the intent of the test.

Here is the pattern I followed:

// Before: importing Material when it is not needed
import 'package:flutter/material.dart';

testWidgets('autofill group test', (WidgetTester tester) async {
  await tester.pumpWidget(
    MaterialApp(
      home: AutofillGroup(
        child: Column(children: [...]),
      ),
    ),
  );
});

// After: using only what the test actually needs
import 'package:flutter/widgets.dart';
import 'package:flutter_test/flutter_test.dart';

testWidgets('autofill group test', (WidgetTester tester) async {
  await tester.pumpWidget(
    Directionality(
      textDirection: TextDirection.ltr,
      child: AutofillGroup(
        child: Column(children: [...]),
      ),
    ),
  );
});

After making the changes I ran the tests locally:

flutter test packages/flutter/test/widgets/autofill_group_test.dart

All tests passed. Then I created the PR.

Step 4: Writing a Good Pull Request

The PR description matters as much as the code. Flutter maintainers review dozens of PRs. A clear, well-written description gets reviewed faster and builds trust with the team.

For each of my PRs I included a reference to the parent issue (#177414), a plain description of what I changed and why, and confirmation that I had run the relevant tests locally.

My commit message format was consistent across all four PRs:

Remove Material dependency from [filename]

Part of #177414

Step 5: The Review Process

This is the part most people are afraid of. Google engineers reading your code.

The reality is that Flutter maintainers are professional and constructive. They want contributions to succeed. On PR #181951 (Move SelectionArea web test from widgets to material folder) I received 17 review comments. On #181903 I received 12. These were not rejections. They were detailed, specific feedback that made the final code better.

The review on #181951 was particularly educational. The SelectionArea web test needed to move from the widgets test folder to the material test folder because it relied on material-specific behavior. A reviewer caught a subtle dependency I had missed and walked me through the correct fix. That kind of direct feedback from framework engineers is genuinely invaluable.

I addressed every comment, pushed updates, and waited for re-review. The turnaround was faster than I expected.

The 4 Merged PRs

Here is the full list of what got merged:

PR #181903 — Refactor autofill_group_test.dart to remove Material dependencies
Merged February 19. 12 review comments. Tagged: framework.

PR #181951 — Move SelectionArea web test from widgets to material folder
Merged February 19. 17 review comments. Tagged: f:material design, framework.

PR #182141 — Remove Material dependency from transformed_scrollable_test.dart
Merged February 13. Tagged: f:scrolling, framework.

PR #182211 — Remove Material dependency from semantics_keep_alive_offstage_test.dart
Merged February 13. Tagged: a:accessibility, framework.

Each one built on the last. By the fourth PR I knew exactly what reviewers would look for and I addressed those things proactively in the code before they asked.

What Contributing to Flutter Actually Taught Me

The technical lesson is about dependency management and layered architecture. The Flutter framework is deliberately structured so that lower-level packages do not depend on higher-level ones. When test files break that rule, even accidentally, it signals a coupling problem that could affect how the framework evolves. Understanding this made me a better architect in my own apps.

The broader lesson is about reading a large codebase with confidence. When I started, flutter/flutter felt enormous and intimidating. After four PRs, I navigate it comfortably. That skill transfers directly to joining any large engineering team or contributing to any open source project.

The professional lesson is that open source contributions are not just resume lines. The review conversations, the back-and-forth with maintainers, the process of getting your code to a standard that ships in a framework used by millions, that is real engineering experience that very few developers have.

How to Start Your Own Flutter Contribution

Go to github.com/flutter/flutter/issues/177414. There are still files in the issue that need fixing. Pick one that has not been claimed, follow the pattern I described, and submit a PR.

Read CONTRIBUTING.md before you touch any code. Set up Flutter from source. Run the tests locally before pushing anything. Write a clear PR description that references the issue.

The Flutter team is genuinely welcoming to new contributors. The codebase is well-documented. And seeing your name in the merged commits of a framework used by millions of developers worldwide is worth every hour of the process.