Use case

When using the gen_defaults tool to automatically generate the Flutter code based on the Material 3 design tokens, it currently warns about tokens that are referenced but do not exist. This is great to detect when a token in the spec has been removed/renamed and one of the templates is using it.

The problem is that there are many false positives (image below), making it hard to distinguish actual problems from regular templating usage. With regular usage I mean cases where you look up a token, and use it if available, or provide a fallback value.

Another problem is that it's failing to detect issues for color tokens, which could be considered the most noticeable. For example, "$tokenGroup.with-icon.icon.color" is not available anymore in the chip spec.

Current warnings:

Proposal

My proposal is to provide a getTokenOrNull for cases where a token is used unconditionally, and it doesn't matter if the token exists or not, because a fallback is provided. This can be used for the border template, which logs many of the false positives above, with height and width being missing.

Additionally, the color template can conditionally log or not the usage of the token based on the default value being available or not. That way, if one template would use color("foo") and foo doesn't exist, it will warn about it. But if a template uses color("foo", "Colors.transparent"), foo not being available won't be logged because a default value is being explicitly provided. So it's like the template contemplates the possibility that the token can exist or not.

These 2 changes would let the tool log the false negatives and hide the false positives.