Dartdoc: 为颤振插件生成的文档还包括飞镖：文档

这是一个 dartdocs.org 错误，但我不清楚 dartdocs.org 到底是哪种错误。

我的猜测是，这可能与颤振运送他们自己的 SDK 和 dartdocs.org 没有在命令行上明确排除颤振 SDK（或错误地包括它）有关。

在生成的文档中包含dart:ui似乎证实了这一假设。

https://www.dartdocs.org/documentation/url_launcher/0.4.1/log.txt

日志表明 dartdoc 没有认识到颤振 SDK 不是包的一部分。 但为什么不是很清楚。

@jcollins-g 如果您需要本地复制，这些步骤对我有用：

git clone https://github.com/flutter/plugins.git
cd plugins/packages/url_launcher/
export FLUTTER_ROOT=<path to where you have flutter>/flutter
dartdoc

有任何消息@jcollins-g 吗？

我可以重现它，并正在研究一组命令行标志，供您在我提出更永久的修复时使用。

@mit-mit 使用以下命令行标志解决：

--exclude dart.collection,dart.math,dart.core,dart.developer,dart.io,dart.ui,dart.isolate,dart.convert,dart.async,dart.typed_data

无论有没有真正解决这个问题，这都是安全的。

降级到 P2，因为有一种解决方法，但仍会尝试尽快修复此问题。

这不再需要在头部； SDK 计算现在足够智能，不会尝试将 SDK 组件包含在 Flutter 插件中。

@jcollins-g 这是否修复$ dartdoc试图解析一大堆与我的颤振应用程序无关的文件？

输出.txt

@jcollins-g 这种解决方法对我不起作用。 它仍在解析一大堆文件，这些文件位于我项目的lib/目录之外！

嗨@devxpy ，

dartdoc 解析通过项目的导入导出树可访问的所有包中的所有文件（这个问题是有时我们认为我们需要在不合适的情况下记录其中的一些文件），这是预期的行为。 由于 dartdoc 的宏和注释引用范围的工作方式，它需要这样做，尽管它可能可以优化为仅按需执行此操作。

如果它正在为不应该的东西生成文档，那么这个或另一个错误都适合打开。

尽管它可能可以优化为仅按需执行此操作。

当前机制不缓存东西？
因为它目前会再次解析所有内容，这对于一个相对较小的应用程序来说需要非常长的时间。

@devxpy

可悲的是，不，它不缓存，因此确实需要很长的时间。 我对如何改进有一些想法，但是 dartdoc 的性能并没有足够高的优先级来分配时间。

@devxpy简单地说，缓存对于 dartdoc 来说并不简单，因为看似不相关的文件的更改可能会影响为另一个文件生成的文档。 这是由于全局范围宏和一些注释引用可以具有以及 dartdoc 的公共接口规范化。 解决此问题的设计将具有一些启发式方法来消除常见情况下的这些问题，或者我们可以更改一些范围规则，然后在检测到更改时采用分析服务器的目标失效策略。 在任何一种情况下都不是微不足道的工作量（尽管肯定不是不可能的）

谢谢你的详细解释！

@jcollins-g 基于文件观察器的“热重载”编译器会花费类似的精力吗？

@devxpy确实，我会说更多的努力。 在https://github.com/dart-lang/build有一群人在做类似的事情，Flutter 当然也支持热重载。