Open dcharkes opened 2 months ago
@bdero Just a heads up, we might break the metadata soon (or temporarily remove it until we find an API that we want to add to do this).
As a workaround, you could try to build the compiler in my_compiler/hook/build.dart
and do dart run my_compiler:main
to run my_compiler/bin/main.dart
which would do the compilation inside my_package_using_compiler/hook/build.dart
.
I thought I had posted an API sketch here earlier, but apparently I didn't.
My current way of thinking is:
void addAsset(
Asset asset, {
Iterable<Uri>? dependencies,
bool forBuildHooks, // if true, not bundled, but available to build hooks that have this build hook as direct dependency
String? linkInPackage, // if set, not bundled directly but sent to specific link hook
});
This way we can properly track dependencies per asset no matter where these assets are wired to:
The API is starting to look a bit overloaded with arguments. I wonder if there is a way to simplify this. Maybe use asset types instead? This would make asset creation a bit more nested.
class MetadataAsset {
final Asset asset;
}
class LinkableAsset {
final String targetPackage;
final Asset asset;
}
@lrhn, as you like to simplify APIs :)
The API is starting to look a bit overloaded with arguments. I wonder if there is a way to simplify this. Maybe use asset types instead? This would make asset creation a bit more nested.
class MetadataAsset { final Asset asset; } class LinkableAsset { final String targetPackage; final Asset asset; }
@lrhn, as you like to simplify APIs :)
Or maybe we should have a "Routing" (name tbd) param instead. That would also give us a place to document the behavior.
addAsset(
Asset asset, {
Routing routing = const Routing.bundleInApp,
});
final class Routing {
/// This asset will be bundled in the app by the Dart or Flutter SDK.
static const Routing bundleInApp;
/// This asset is available in build hooks of which the packages have a
/// direct dependency on the package with this build hook.
static const Routing forBuildHooks;
/// The asset will not be bundled during the build step, but sent as input to
/// the link hook of the specified package, where it can be further processed
/// and possibly bundled.
factory Routing.linkInPackage(String packageName)
}
We currently have 3 types of output of a build hook:
The most common use cases for metadata are:
Maybe there are other use cases but, we haven't come up with them yet.
If there's a use case for structured data, it might be fine to just put that structured data in a json file and make it a data asset.
Unifying these 3 types of assets would:
addAsset(...)
for assets for bundling andassetAsset(linkIn: 'some_package', ...)
for sending it to a link hook, andaddMetadata(...)
for sending info to another build hook.)Then we need to come up with some name for these 3 types of "buildables".
Thanks @mosuem @mkustermann @liamappelbe @HosseinYousefi for the input! And please leave any other thoughts and suggestions.