当前,我们的几乎所有包都包含支持创建示例时的标准平台的示例应用程序。我们的例子有以下几个用途:
- 演示如何使用该包(例如,
main.dart
在 pub.dev页面上显示) - 作为许多包中README代码摘录的来源。
- 在CI中运行集成测试。
- 在CI中运行原生插件单元测试(适用于大多数平台)。
- 让人们可以在本地运行该包以尝试(无论是用于评估,还是用于包开发)。
用途1和2不需要平台支持,只需要Dart代码。3和4肯定需要将示例应用程序提交到版本控制系统中,但只适用于一部分包(所有插件都需要它,但我们很少有非插件包具有集成测试)。5可以应用于任何包,但不太可能成为常见的用例。
为了案例5而保留大量的平台支持代码是没有必要的。我们可以为没有需要example
的测试的应用程序删除所有平台目录,并在示例目录中放置一个README,说明要在本地运行flutter create --platforms=<foo> .
。这个步骤非常快,所以这不会带来太大的负担。
优点:
- 更少的维护开销。我们拥有的每个增量平台目录都有一个小但非零的成本,形式化为我们需要定期检查并避免本地杂乱无章的事情,如dependabot PRs或自动迁移等。
- 更少的CI开销。我们目前在CI中构建我们找到的每个示例,以确保它们保持可构建状态。(写到这里,这仅适用于自动滚动器和对工具或CI配置等仓库范围内容的更改,因为仅涉及单个包的PR仅针对这些包在CI中进行目标。)
- 更小的包下载。每个客户端都会下载整个包,包括
example/
中的所有内容。 - 平台之间的一致性。我们将避免诸如由于包早于Windows成为
example/windows/
支持的平台而没有create
的情况这样的问题。(当然,我们可以通过一次性遍历仓库来解决这个问题。)
缺点:
- 在本地运行示例时更复杂的情况:执行此操作的人需要弄清楚他们需要这样做,或者找到文档说明他们需要这样做。
- 包之间的不一致性。具有集成测试的包将有示例,其他包则没有,因此任何运行多个包示例(例如,Flutter团队成员)的人可能会感到困惑。
- 过时的本地平台目录。与仓库进行长时间交互的人有时会遇到破坏性的问题,他们现在不知道如何重新生成本地应用程序。例如,如果我现在在一个Android上运行一个包一次,然后一年后在一个更新后的仓库副本中再次运行它,它很可能仍然有效,因为更新已经检查过。但是在这种情况下,我将有一个一年前的
android/
目录,它很可能已经过时了。 - 没有明确表示平台支持选择的方法。例如,
xdg_directories
在其示例中只有一个linux
目录的原因是有道理的。 - 关于互联网访问权限等问题的一些复杂性。@jmagman指出,我们可以只留下需要编辑的那些文件,这样事情就会“一切正常”。但是要注意的是,将其留在那里但不完整可能会让人们感到困惑,甚至让工具感到困惑。
2条答案
按热度按时间oyt4ldly1#
将README文件放入示例目录,告知在本地运行
flutter create --platforms=<foo> .
。这一步相当快,所以这不会带来太大的负担。理想情况下,工具应该知道它在插件的顶级运行
run
/build
时使用示例目录,这样你就不必总是看到这个消息:到那时,你可以这样做:
flutter/packages/flutter_tools/lib/src/commands/packages.dart
第384行至第387行 80f2dd4
| | if (example && rootProject.hasExampleApp && rootProject.example.pubspecFile.existsSync()) { |
| | finalFlutterProject exampleProject = rootProject.example; |
| | await exampleProject.regeneratePlatformSpecificTooling(); |
| | } |
这里:
flutter/packages/flutter_tools/lib/src/project.dart
第346行至第350行 80f2dd4
| | Future regeneratePlatformSpecificTooling({ |
| | DeprecationBehavior deprecationBehavior =DeprecationBehavior.none, |
| | Iterable? allowedPlugins, |
| | }) async { |
| | returnensureReadyForPlatformSpecificTooling( |
至少就目前而言,仍然需要存在一个
ios
目录来显示其支持,但它可以是空的(尽管我没有测试过,所以可能还有更多的事情要做)。理想情况下,工具逻辑可以从pubspec中获取平台支持,因此该目录不再是表示平台支持的东西。xghobddn2#
在那个时候,你可以这样做:
关于
regeneratePlatformSpecificTooling
的注解表示它应用模板文件,但看起来它并不像create
模板。我认为我们没有什么东西可以实时执行create
。理想情况下,工具逻辑可以从 pubspec 中获取平台支持,因此目录不再是表示平台支持的东西。现在这是可行的;pubspec.yaml 添加了一个
platforms:
键,允许非插件包声明支持的平台,因此我们可以构建工具逻辑,它会执行以下操作:flutter:plugins:
平台,则尊重它们;否则platforms:
平台,则尊重它们;否则尽管
web
可能存在潜在的问题,因为 pub.dev 从包含的内容中自动识别出 web 支持,所以不支持 web 的包不太可能有一个列出除了 web 之外的所有内容的platforms:
条目。