[native_assets_cli] Package name #999
Comments
|
Would it make sense to go away from "native" and from "assets" and instead use |
|
I think I'd prefer What's a good name for the "build hook" and "link hook"? (I think they should live in the same package, as they will have many shared classes.) |
|
Notes from discussion with @mosuem
( |
|
Throwing some nice not-as-technical names in the ring: |
|
From discussion with @mkustermann @HosseinYousefi @mosuem:
Which might conflict with |
|
@HosseinYousefi I need an email to use to transfer to |
|
I sent the invite to [email protected] |
We can move this conversation to email. I think @mosuem had already contacted you, let's talk about the correct email there. |
Thanks @influx6! I have accepted the invite. 👍 @jonasfj Is marking the |
|
@influx6 You might want to update the readme on the repo that it's discontinued and archive the GitHub repo. Given that the SDK constraint is |
No, it's not.
The rules on similar package names are there to prevent typo squatting attacks. But if we can see that it's not an attack, we can make exemptions on a case by case basis. In a case like this, where:
Formally, this is done by adding Once deployed a Googler can create the package, and transfer it the people who requested it be created. In this case, that'd be you, so really you could just create it. |
|
If we're going for Because we will start name spacing with package name (#2132), we need to decide on those package names now. Should we consider |
Yes (let the bike shedding stop 😉 ). I am also fine with |
|
The majority of packages related to icon, font, asset have plural names on pub.dev, so I'm leaning towards plural for For the So should |
Bug: #999 A package name is either a verb, a singular noun, or a plural noun. Since this package name is a noun and there is more than one hook (build hook and link hook), rename the package to a plural noun.
This PR tries the curate the classes which are in the public API of `native_assets_cli.dart` and adds some documentation to them. * `(Build|Link)(Input|Output)` refer to the hooks the are the input or output of. * `Hook(Input|Output)` refer to the subclasses * `(Build|Link|Hook)Config` refer to the input they are the config of. * `XXXBuilder` refer to the class they build. * `Builder|Linker` refer to the hooks they should be used in. * `EncodedAsset` refers to protocol extensions for encoding/decoding * `PackageMetadata|PackageUserDefines|PackageUserDefinesSource` refer to the classes where they are used. * `ProtocolExtension` documents it's the specification for an extension of the base protocol. * `AssetRouting|ToAppBundle|ToBuildHooks|ToLinkHook` refer to each other in the hook output. Deprecated classes have been removed: * `Metadata|Dependencies` these were no longer used since the `XXXBuilder` pattern. Classes only used in `package:native_assets_builder` have been moved there: * `Target`. The Dart docs can be inspected by `pkgs/native_assets_cli$ dart doc .`. TODOs: * This PR does not yet curate extension types, extensions, and top level functions. * This PR does not yet curate the `code_assets.dart` and `data_assets.dart` libraries. Context: * Work before splitting up the package: #999
This PR tries the curate the toplevel functions which are in the public API of what will be `package:hooks`, `package:code_assets` and `package:data_assets`. The validate functions for the base protocol are moved into a `ProtocolBase` class. (These need to be public because `package:native_assets_builder` uses them. And these need to be in `package:native_assets_cli` because the `test` methods use them.) The Dart docs can be inspected by `pkgs/native_assets_cli$ dart doc .`. TODOs: * This PR does not yet curate extension types, and extensions. Context: * Work before splitting up the package: #999
This PR replaces all extension types with classes. This PR renames all classes that mostly belong to another class to start with the name of that class. I'm not entirely satisfied with how this looks, but I think it's a step in the right direction. The Dart docs can be inspected by `pkgs/native_assets_cli$ dart doc .`. Open question: * Should we _not_ export all those helper classes? That would prevent users using these types in their code. But this would be considered a leaked symbol. So this probably doesn't work. * Should we not generate dartdocs for those helper classes. They usually simply have an `add`, `addAll` or `operator []`. The interesting doc comments are on the accessors that return those classes. Context: * Work before splitting up the package: #999
After we add support for
hook/link.dartwe'll have aLinkConfigandLinkOutputthat will share some types with theBuildConfigandBuildOutput.And after adding
DataAssets we'll have more assets thanCCodeAssets/NativeCodeAssets.So, the question is what this package should be renamed to:
build_hook/build_script([native_assets_cli] data assets #154 (comment)). But that wouldn't fit well with also having thehook/link.dartprotocol.build_protocol,build_config_cli,build_hook_cli,build_hook_protocol([native_assets_cli] Redesign API step 1 #946 (comment)) Ditto, it wouldn't fit well with also having thehook/link.dartprotocol.Original tracking issue:
cc @mosuem @mkustermann
The text was updated successfully, but these errors were encountered: