Note that as written today, this macro will have issues if any other macro runs on the same file, and uses an identifier to reference something from dart:core. The reason is that if an Identifier is used, that will add a prefixed import to dart:core, which will end up breaking the raw string references to core types (they will need the prefix).
We don't yet have a real API for getting these identifiers, but you can for now use the deprecated resolveIdentifier API, to get identifiers for these types, which will work :).
It is a bit annoying though, long term we are looking at something like the reflected imports proposal.
We might also always add a prefixed import of dart:core just to help macro authors avoid this issue, since it is a bit of a trap for sure today (it works until another macro uses an identifier from dart:core).
Note that as written today, this macro will have issues if any other macro runs on the same file, and uses an identifier to reference something from
dart:core
. The reason is that if an Identifier is used, that will add a prefixed import todart:core
, which will end up breaking the raw string references to core types (they will need the prefix).We don't yet have a real API for getting these identifiers, but you can for now use the deprecated
resolveIdentifier
API, to get identifiers for these types, which will work :).It is a bit annoying though, long term we are looking at something like the reflected imports proposal.