Repository navigation
Style guide changes for package-private APIs and enums #193960
Description
Currently, the styleguide suggest no package private, but in practice, it is not followed. Some of the examples are experimental APIs or just something that can change frequently and is not meant to be consume publicly.
Instead of forcing them public and without any guardrail for consumption and breaks people. We should think about whether we should change the guideline to be permissive in this matter while adding guardrail so consumer won't accidentally use these classes without knowing they can breaking frequently.
As part of this, we should also thinking about enum in public API as current lint and guideline suggest exhaustive switch case to handle enum, which is not the most appropriate way to consume some the enum API.
This proposal directly contradict #108632.
Activity
stuartmorgan commentedon Oct 7, 2026
FYI I filed that because I was surprised when I discovered that this was a style rule, since as far as I could tell flutter/packages had never actually followed that rule (I don't have context on that from before I was lead for that repo, but I didn't see any evidence that it was generally applied). I don't actually agree with the rule, which is why I never prioritized that issue; my experience in my time in flutter/packages is that following the Dart convention of things in lib/src not being exported unless re-exported worked quite well in practice despite the risk of accidental exporting.
(I also strongly disagree with the rationale in the style guide that '"Private" files can still be imported so they are still actually public APIs'; I saw no evidence in years of development that people publishing packages that violated the import rules was a problem that happened at any meaningful scale.)
tl;dr: please don't construe me filing that issue as an argument against the RFC :)