Question 1

TypeScriptのexactOptionalPropertyTypes有効時に"Type 'undefined' is not assignable to type 'Timeout'"エラーを修正する方法

Accepted Answer

`@cordisjs/plugin-include` 1.0.4 では、オプションプロパティの型に `undefined` を明示的に含めてください。`packages/include/src/index.ts` において、次のコード：

```ts
private writeTask?: NodeJS.Timeout
```

を以下のように変更します：

```ts
private writeTask?: NodeJS.Timeout | undefined
```

これは型のみの変更であり、ランタイムの動作は変わりません。明示的に `undefined` が代入されている他のオプションプロパティにも、同様に `T | undefined` への拡張を適用してください。アップストリームのリリースを待っている利用者は、`patch-package` を使って公開されている型宣言にパッチを当てることができます。

Question 2

なぜ Cordis プラグインは、その Context が dispose された後でも読み込まれ続け、dispose イベントが一度もトリガーされないのですか?

Accepted Answer

これはCordisのバグでした。親コンテキストが破棄された後に`ctx.plugin()`を非同期で呼び出すと、子プラグインがインストールされてしまい、その副作用がクリーンアップされないまま残る可能性がありました。コミット`fc388fdbabb9642d3b5b1440573d96cda25604a3`を含むリリースにCordisをアップグレードしてください。この修正後は、破棄されたコンテキストに登録されたプラグインはアクティブ化されなくなります。一時的な回避策として、非同期のプラグイン登録を自分でガードしてください：

```ts
let disposed = false

ctx.on('dispose', () => {
  disposed = true
})

setTimeout(() => {
  if (disposed) return
  ctx.plugin((ctx) => {
    ctx.on('dispose', () => {
      // クリーンアップ
    })
  })
}, 100)
```

Question 3

Cordisパッチが同じインクルードリスト内の先行するパッチによって挿入された行を対象としている場合、「patch: entry not found」をどのように修正すればよいですか？

Accepted Answer

これは、`@cordisjs/plugin-include` がパッチを適用する前に `entryMap` を一度だけ構築するために発生します。`insert` パッチで追加された行はそのマップに追加されないため、後続のパッチがそれらの ID を解決できません。修正方法は、PR #116（またはそれに取って代わる journal 修正）を含むリリースにアップグレードすることです。この修正では、挿入された行が挿入直後にインデックス化されます。ローダーをローカルで保守している場合は、処理を続ける前に `insert` ブランチ内で `buildMap(insert)` を呼び出してエントリマップにマージしてください（再帰的なグループエントリも含めて）。一時的な回避策としては、最終状態を挿入行に直接指定する（例：`insert: [{ id: 'added', name: 'plugin-c', disabled: true }]`）、または insert とその後の変更を2つの独立した include/patch パスに分割して、両者の間でマップが再構築されるようにする方法があります。更新は次のコマンドで行います：`npm update @cordisjs/plugin-include`。

Question 4

dispose() を呼び出した後に cordis の fiber.state がいつまでも PENDING または UNLOADING のままになってしまうのはなぜですか？

Accepted Answer

これはcordisのバグです：`state`は`_updateState()`によってのみ再計算されるキャッシュ済みフィールドであり、`_setEpoch()`内の早期リターンにより、dispose時点でACTIVEではなかったすべてのfiberについてその再計算がスキップされます。これが影響するのは正確に2つのケースです：必要な依存関係が一度も提供されなかったためにPENDINGで止まっているfiberと、ロード中にプラグインが例外をスローしたfiber（UNLOADINGで止まっているもの）です。回避策：(1) disposeの検出には`fiber.state`ではなく`fiber.uid === null`をチェックしてください — uidはdispose時にnullに設定され、内部の`_getState()`はすでにnullのuidを`FiberState.DISPOSED`にマッピングしています。(2) あるいは、disposeエフェクトが最後にstateを収束させるように`fiber.ts`にパッチを適用してください：`while (this.inertia) { await this.inertia }`ループの後に、`this._updateState(() => {})`の呼び出しを1つ追加します。この変更により、すべてのケースがDISPOSEDに収束し、disposeは正しく`PENDING -> DISPOSED`のinternal/statusイベントを発行し、cordisの全テストスイート（246テスト）がパスします。

cordis

概要

README プレビュー

FAQ (4)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter