複製手順:
# Extract package:retry version 3.0.1
$ curl -L https://storage.googleapis.com/pub-packages/packages/retry-3.0.1.tar.gz | tar -xz
$ pub get
# Get dartdoc from git
$ mkdir /source/dartdoc
$ git clone https://github.com/dart-lang/dartdoc.git /source/dartdoc
$ cd /source/dartdoc; pub get; cd -;
# Generate docs
$ dart /source/dartdoc/bin/dartdoc.dart
ことに注意してくださいpubspec.yaml
についてpackage:retry
あります。
environment:
sdk: ">=2.0.0 <3.0.0"
そして.dart_tool/package_config.json
はpackage:retry
言語バージョン2.0を指定します:
{
"configVersion": 2,
"packages": [
/* various other dependencies, mostly test and it's transitive dependencies, omitted here */
{
"name": "retry",
"rootUri": "../",
"packageUri": "lib/",
"languageVersion": "2.0" // <-- language version 2.0, hence, no library in package:retry supports null-safety
}
],
"generated": "2020-10-21T10:44:27.912220Z",
"generator": "pub",
"generatorVersion": "2.10.0"
}
予期しない結果:
retry
関数がnull
返すことができないのは正しいですが、パッケージはnull-safetyに移行されないので、ここに何らかのnull-safetyタグを追加する必要がありますか?
ノート。 個々のライブラリがnull-safetyをオプトアウトできるのは正しいことです。したがって、関数またはクラスがnull-safetyをサポートしているかどうかに注釈を付けることは価値があると主張できます。
ただし、null-safetyに移行されるほとんどのパッケージでは、すべてのライブラリがnull-safetyに移行されます。
編集:ここで何をすべきか完全にはわかりません。 言語バージョン> = 2.12.0を持たないパッケージのライブラリに「null-safety」を追加することはおそらく間違っています。
これはおそらく間違っていることに同意します。 ここで何が起こっているのかわかりませんが、明日調べようとします。 それが広まっている場合(つまり、何らかの理由でこのようにすべてをマークしている場合)、おそらくP1に昇格する必要があります。
アナライザーは、これらがnullセーフパッケージではないという真実をまだ知っていることを知っていますが、現在、nullセーフティタグをいたるところに散らばっています。
@ jcollins-gメンバーレベルでこのタグが必要になることはありますか? 他の場所、たとえばpub.devでは、nullの安全性をパッケージレベルのプロパティとして扱います(パッケージ全体に含まれるかどうかにかかわらず)
@ mit-mitどちらにしても強い意見はありません。 APIドキュメントのコーパスを閲覧し、パッケージの境界を越えるとき、nullセーフパッケージに遭遇した(または出た)ときを知るのは良いことかもしれないという議論があります。メンバータグはそのための1つの方法です。それ。
ここに置けますか?
APIドキュメントのコーパスを閲覧し、パッケージの境界を越えるとき、nullセーフパッケージに遭遇した(または出た)ときを知るのは良いことかもしれないという議論があります。メンバータグはそのための1つの方法です。それ。
ヌルセーフパッケージからヌルセーフではないものにつまずく可能性は一般的にありますか?
pub.dev
、 pana
pub.dev
の分析は、次の場合にのみ、パッケージをnull-safetyを
>=2.12
、// @dart=2.5
)を使用してnull-safetyをオプトアウトしていません。pub upgrade
解像度のすべての依存関係( dev_dependencies
を除く)は、null-safety_をサポートします(この再帰的定義に従います)。したがって、nullセーフをサポートするパッケージのドキュメントを読み始めた場合、nullセーフではないパッケージ/ライブラリに誤って遭遇する可能性はほとんどありません。
ただし、nullセーフではないパッケージから開始する場合は、逆の方向に進むことができます。 そして、グーグル検索でそれを見つけてドキュメンテーションページにたどり着いたら、それも知っておくといいと思います。 したがって、ライブラリレベルのラベルが適している可能性があります。
これはhttps://github.com/dart-lang/sdk/issues/43903のために解決するのが難しい問題であることが判明しました。これは、実験フラグとその使用方法のためにも解決するのが難しい問題であると私は理解してい
いくつかの悪いニュース。 フラグをオンにデフォルト設定しても、実際には問題は解決しません。 したがって、この問題を修正するには、追加の作業が必要です。 幸いなことに、 手間のかかる作業を行っていますが、更新してWindowsの互換性の問題を修正する必要があります。 その作業が着陸したら、このバグを修正できるはずです。
現在、#2309に基づいてPRを開始し、彼が遭遇した問題を修正し、マージの競合を解決しています。
この問題を修正するために#2309の更新バージョンを使用しようとすると、問題が発生しました。 短いバージョンでは、dartdocはデフォルト以外のリゾルバーを必要とするいくつかのことを許可しているため、一部のテストは失敗します。 これはおそらく解決可能ですが、時間枠内ではありません。
それを「修正」する2回目の試みは、dartdoc内のpubspec読み取りロジックを再実装しただけです。 これはばかげていましたが、うまくいったでしょう。 @scheglovは、これはパッケージをAnalysisDriverに渡さなかったことが原因である可能性があると指摘しましたが、実際、これを行うことができませんでした。
AnalysisContextCollectionへの移植をその債務への対処の失敗として処理するためにバグ#2410を提出すると、将来、このようなより紛らわしい問題が発生することは間違いありません。
null安全タグの位置の変更に関する@ mit-mitのコメントを実装するためにバグ#2409を提出しました。
#2411が着陸した後、閉じて新しいバージョンを公開するために移動します。