You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mkustermann suggested that BuildInput should provide a list of support asset types.
Providing any assets in the BuildOutput that are not supported is an error.
This would enable other embedders/launchers to support their own asset types, without making PRs to this package.
Some open questions:
How are such assets versioned? If such asset type wants to do a breaking change, it wouldn't be covered by the protocol version. Leading to runtime failures.
How should asset types be name spaced? How do we avoid name collisions on a String type? Should embedders/launchers register a package according to their name on dartdev and use that (or prefix with that)?
The text was updated successfully, but these errors were encountered:
@mkustermann suggested that
BuildInput
should provide a list of support asset types.Providing any assets in the
BuildOutput
that are not supported is an error.This would enable other embedders/launchers to support their own asset types, without making PRs to this package.
Some open questions:
String type
? Should embedders/launchers register a package according to their name on dartdev and use that (or prefix with that)?The text was updated successfully, but these errors were encountered: