@dnfield could we possibly loosen some of the error cases to make this non-breaking? Specifically, we could allow (with a warning) the case where the kernel still contains references to icons that don't exist as assets

If a kernel has references to a font that isn't present, that's a bug. The fact that we're failing earlier should not be considered a breaking change IMO - if you try to use an icon from a non-existant font, you'll get undefined behavior at runtime. You'll end up with either an arbitrary character from a fallback font, or (more likely), a replacement character or some garbage in your application.

For now we'll need to disable for web then.

On the other side, I disagree that it is a bug. There are plenty of code patterns that would lead to icons being retained but not actually used. For example, a pattern like the following will not tree shake:

Widget build(BuildContext context) {
  switch (data) {
    case 'material':
       return WidgetWithMaterialIcon();
     case 'cupertino':
       return WidgetWithCupertinoIcon();
  }
}

If data comes from an API endpoint, the compiler will never be able to remove the cupertino path. Despite that, the author may know with certainty that their endpoint will always return material. In fact, this code could be present in a third party dependency of that authors code in such a way that is not obvious.

Is tree-shake-icons a way to reduce bundle size, or an icon usage linter? Its going to be very difficult to roll out both of these at once. If you really want the later behavior I would strongly consider staging that as a warning first and doing a gradual breaking change.

And I'm also concerned that we'd be really depending on the specific implementation of tree shaking, despite the fact that the Dart team has provided no formal guidance or guarantees on how it applies: dart-lang/sdk#33920

Someone who wants to use that pattern cannot tree shake thier icons. They would have to opt out. Perhaps we could make this just print a warning and opt them out, and the warning could be suppressed if they explicitly opted out.

As far as implementation details go, I'm not sure what else to do there. The only concern would be if they changed the way apt/tfa const evaluation worked. That seems pretty safe to me.

How would a user know that they have un-treeshakeable code if there is no guidance or documentation on how tree shaking works?

I think we should just let them know that their icon fonts cannot be shaken given the state of their code. We could create a wiki or doc page explaining that for Icons to be shakeable, they have to be const, and that any reachable code has to include the referenced font.

FYI @zanderso

Updated to not adjust the error behavior for now

Yes, its still off by default. Whether or not we can turn it on for web depends on the outcome of a discussion involving @dnfield when he gets back