Repository navigation
Conversation
| // ignore: deprecated_member_use | ||
| import 'package:test_api/test_api.dart' as test_package; | ||
|
|
||
| import '_leak_tracking.dart'; |
There was a problem hiding this comment.
Because this is internal library, not exposed in API.
There was a problem hiding this comment.
Everything under lib/src is private unless it's exported by something in lib
There was a problem hiding this comment.
Our general policy is to export everything. Those underscore libs there are a somewhat special case, they contain the platform-specific implementation (see the io vs web suffix) for certain features and are used with conditional imports. The library that imports these files conditionally do exports the full API.
There was a problem hiding this comment.
If you want to keep this private, why not just add it as a private method to the file where it is used?
There was a problem hiding this comment.
Reasoning to have code separately can be size of the library widget_tester.dart. We want to keep it reasonable and collect everything related to leak tracking, separately.
Merged 'leak_tracking.dart' and '_leak_tracking.dart'
| /// The Flutter related enhancements are: | ||
| /// 1. Listens to [MemoryAllocations] events. | ||
| /// 2. Uses `asyncCodeRunner` for async call for leak detection. | ||
| Future<void> withFlutterLeakTracking( |
There was a problem hiding this comment.
Isn't this method duplicated from elsewhere in the framework now? Can we remove it from there.
There was a problem hiding this comment.
Yes, this file will be removed in next PR. Added TODO to that method under flutter/test/foundation.
There was a problem hiding this comment.
Can we just fix this up in this PR?
There was a problem hiding this comment.
I would love to do it, but I think it is not possible, because the usage of the new method is in different package. So, it needs the method to be checked in, in order to use it.
|
One disadvantage of adding this functionality to the testing framework is that we are going to lock people into a particular version of the leak_tracking package. If the leak tracking package evolves, people will not be able to benefit from it until we have upgraded the leak tracking version in Flutter and developers have updated to that new version of Flutter. This burden is not to be underestimated. Some people have regretted that their package is actually that closely tied to Flutter releases. cc @dnfield |
| vector_math: 2.1.4 | ||
|
|
||
| # Used by testWidgets. | ||
| leak_tracker: 2.0.1 |
There was a problem hiding this comment.
This is what will become a bit challenging that @goderbauer is referring to.
One option would be to start with this as a dev_dependency until it's been vetted a bit more with the framework tests.
At the same time, we should have a good cycle of time to let this get ready before another stable...
There was a problem hiding this comment.
Is it possible to reference something that is imported in lib/src with dev_dependency?
According to this doc, no: https://dart.dev/tools/pub/dependencies
There was a problem hiding this comment.
To evaluate this with the framework tests we'd ideally keep it as a dev_dependency on the framework. Not super sure how we can do that with how things are currently setup, though. May need some extra thought.
In future, if it starts hurting, we will copy minimal subset of the leak_tracker code to the flutter framework and remove the dependency. Yes, this means one time the users will need to shift to new version of flutter that does not contain the dependency, to use leak tracker. |
| /// When to collect stack trace information. | ||
| /// | ||
| /// You may need to know call stack to troubleshoot memory leaks. | ||
| /// Custonize this parameter to collect stack traces when needed. |
| @Deprecated(_nonBackwardCompatibleApiWarning) | ||
| class LeakTrackingFlutterTestConfig { | ||
| /// Creates a new instance of [LeakTrackingFlutterTestConfig]. | ||
| @Deprecated(_nonBackwardCompatibleApiWarning) |
There was a problem hiding this comment.
It feels odd to check in deprecated code intentionally. @goderbauer @dnfield is there anywhere else in the framework where we do this / is this an acceptable pattern? I know in other places we have _kDebug* flags that can be flipped manually or via a service extension.
I would worry that users would ignore the deprecation warnings and check in usages of LeakTrackingFlutterTestConfig to their repos anyway.
There was a problem hiding this comment.
This is not a pattern we have elsewhere and we shouldn't establish it. I am afraid, this is just teaching people to ignore deprecation warnings, which is not in our interest. It is also not in line with our breaking change policy: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
There was a problem hiding this comment.
General practice would be to evolve the API as a package and then pull it into the framework when it is reasonably stable.
|
|
||
| typedef LeaksObtainer = void Function(Leaks foundLeaks); | ||
|
|
||
| // TODO(polina-c): remove this file once https://github.com/flutter/flutter/pull/124435 |
| // ignore: deprecated_member_use | ||
| import 'package:test_api/test_api.dart' as test_package; | ||
|
|
||
| import '_leak_tracking.dart'; |
There was a problem hiding this comment.
If you want to keep this private, why not just add it as a private method to the file where it is used?
| @Deprecated(_nonBackwardCompatibleApiWarning) | ||
| class LeakTrackingFlutterTestConfig { | ||
| /// Creates a new instance of [LeakTrackingFlutterTestConfig]. | ||
| @Deprecated(_nonBackwardCompatibleApiWarning) |
There was a problem hiding this comment.
This is not a pattern we have elsewhere and we shouldn't establish it. I am afraid, this is just teaching people to ignore deprecation warnings, which is not in our interest. It is also not in line with our breaking change policy: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
| @Deprecated(_nonBackwardCompatibleApiWarning) | ||
| class LeakTrackingFlutterTestConfig { | ||
| /// Creates a new instance of [LeakTrackingFlutterTestConfig]. | ||
| @Deprecated(_nonBackwardCompatibleApiWarning) |
There was a problem hiding this comment.
General practice would be to evolve the API as a package and then pull it into the framework when it is reasonably stable.
|
|
||
| class StatelessLeakingWidget extends StatelessWidget { | ||
| StatelessLeakingWidget({super.key}) { | ||
| // ignore: unused_local_variable |
There was a problem hiding this comment.
There was a problem hiding this comment.
This could just be part of widget_tester_test.dart?
| vector_math: 2.1.4 | ||
|
|
||
| # Used by testWidgets. | ||
| leak_tracker: 2.0.1 |
There was a problem hiding this comment.
To evaluate this with the framework tests we'd ideally keep it as a dev_dependency on the framework. Not super sure how we can do that with how things are currently setup, though. May need some extra thought.
|
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |

Contributes to flutter/devtools#3951