-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[native_assets_cli] Drop Config
suffixes v2
#1830
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with some nits and more docs - but I like this API.
@@ -188,22 +233,22 @@ extension MacOSConfigSyntactic on MacOSConfig { | |||
/// assets (only available if code assets are supported). | |||
extension CodeAssetBuildOutputBuilder on BuildOutputBuilder { | |||
/// Provides access to emitting code assets. | |||
CodeAssetBuildOutputBuilderAdd get codeAssets => | |||
CodeAssetBuildOutputBuilderAdd get code => | |||
CodeAssetBuildOutputBuilderAdd._(this); | |||
} | |||
|
|||
/// Supports emitting code assets for build hooks. | |||
extension type CodeAssetBuildOutputBuilderAdd._(BuildOutputBuilder _output) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name is giving me Java flashbacks - how about CodeAssetCollector
?
/// Code asset specific configuration. | ||
CodeConfig get codeConfig => CodeConfig(this); | ||
// Weird class that combines `CodeConfig` getters and a getter for code assets. | ||
class LinkCodeConfig implements CodeConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed a bit ugly, but I don't know a way around it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem very right to me. It mixes orthogonal concerns (code configuration and outputed assets)
null => | ||
throw StateError('Cannot access iOSConfig if targetOS is not iOS' | ||
' or in dry runs.'), | ||
IOSConfig get iOS => switch (_iOSConfig) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Why a switch instead of a simple if
check?
@@ -212,65 +257,73 @@ extension type CodeAssetBuildOutputBuilderAdd._(BuildOutputBuilder _output) { | |||
/// assets (only available if code assets are supported). | |||
extension CodeAssetLinkOutputBuilder on LinkOutputBuilder { | |||
/// Provides access to emitting code assets. | |||
CodeAssetLinkOutputBuilderAdd get codeAssets => | |||
CodeAssetLinkOutputBuilderAdd get code => | |||
CodeAssetLinkOutputBuilderAdd._(this); | |||
} | |||
|
|||
/// Extension on [LinkOutputBuilder] to emit code assets. | |||
extension type CodeAssetLinkOutputBuilderAdd._(LinkOutputBuilder _output) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly verbose as above - and not very understandable...
Based on recent discussions with @mosuem @liamappelbe about what is used to hash the build directory and this PR restructuring, we may want to consider rename a few things and do the following // build hook
main(...) asyc {
await build((BuildInput input, BuildOutputBuilder output) {
input.outputDirectory;
input.config.{code,...} // <-- only this goes into hashing
input.metadata.* // <-- metadata emitted from package deps we can utilize
output.assets.code.add();
});
}
// link hook
main(...) asyc {
await link((LinkInput input, LinkOutputBuilder output) {
input.outputDirectory
input.config.{code,...}. // <-- only this goes into hashing
input.assets.{code,data,...} // <-- symmetric to `hook/build.dart`'s `output.assets.{code,data,...}`
output.assets.code.add();
});
} That would achieve
I prefer we don't use @dcharkes wdyt? |
Thanks @mkustermann and @mosuem for the input! I've replied to the refactoring suggestion in the original thread. Overall SGTM. I'll close this PR.
Please see #1829 where I explored that. |
Addresses:
BuildConfig.targetOS
toBuildConfig.codeConfig.targetOS
, remove it entirely or extend to cover web #1738 (comment)A variant of:
Config
suffixes v1 #1829This PR normalizes the
code
anddata
specific APIs on the config, config builder, output and output builders under a.code
and.data
extension.Example link hook code:
Example build hook code:
This drops
Config
suffixes from the various config accessors.This changes
output.codeAssets.add(
tooutput.code.addAsset(
.The weird quirk in this PR is that it has to provide an API for
LinkConfig.code
that gives both theCodeConfig
getters and anassets
getter. I tried using extension types to alleviate this, but extension types can only extend the type they are extending, not the first element of a tuple they are extending.Separating the
linkConfig.code : CodeConfig
andlinkConfig.assets.code : Iterable<CodeAsset>
leads to a less symmetric API though:Config
suffixes v1 #1829Alternatively, we could also opt to land neither of the PRs. And stick with
config.codeConfig.androidConfig
andoutput.codeAssets
.