Dartdoc: 移行されていないパッケージのnull-safetyアノテーション

作成日 2020年10月21日  ·  10コメント  ·  ソース: dart-lang/dartdoc

複製手順:

# 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.jsonpackage: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"
}

予期しない結果:

3PjXUKmqd6fA2M4

retry関数がnull返すことができないのは正しいですが、パッケージはnull-safetyに移行されないので、ここに何らかのnull-safetyタグを追加する必要がありますか?

P1 bug nnbd

全てのコメント10件

ノート。 個々のライブラリが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つの方法です。それ。

ここに置けますか?

Screenshot 2020-10-22 at 21 05 14

APIドキュメントのコーパスを閲覧し、パッケージの境界を越えるとき、nullセーフパッケージに遭遇した(または出た)ときを知るのは良いことかもしれないという議論があります。メンバータグはそのための1つの方法です。それ。

ヌルセーフパッケージからヌルセーフではないものにつまずく可能性は一般的にありますか?

pub.devpana 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に渡さなかったことが原因である可能性があると指摘しましたが、実際、これを行うことができませんでした。

2411は、正しいパッケージ構造をAnalysisDriverに渡すことで問題を修正し、修正を加えます。

AnalysisContextCollectionへの移植をその債務への対処の失敗として処理するためにバグ#2410を提出すると、将来、このようなより紛らわしい問題が発生することは間違いありません。

null安全タグの位置の変更に関する@ mit-mitのコメントを実装するためにバグ#2409を提出しました。

#2411が着陸した後、閉じて新しいバージョンを公開するために移動します。

このページは役に立ちましたか?
0 / 5 - 0 評価