Reach the index fallbacks when a resource is not on its URI path - #49
Reach the index fallbacks when a resource is not on its URI path#49koriym wants to merge 1 commit into
Conversation
resolveResourceClass listed four resolution strategies, but the third and fourth were unreachable: when the resource was absent from the path its URI names, findFileByRelativePath returned null and the method returned empty instead of falling through. The index strategies only ran for the narrow case of a file that exists at the expected path yet declares no PHP class. That inverted their purpose. Looking the resource up by class name or by filename is what resolves layouts where resources live outside the project root, and those are exactly the layouts the early return rejected. Let each strategy fall through, and guard the two index strategies now that they run: an installed BEAR application ships src/Resource/App/*.php under a namespace ending in \Resource\App\Foo, so it matches both the FQN suffix and the path suffix on shape alone, and resolving to it would send navigation and type inference into a dependency. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. Walkthrough変更概要リソースクラス解決のフォールバック順序を整理しました。PHPインデックスとファイル名インデックスでは、 Changesリソース解決
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The change enables intended fallback resolution and adds vendor filtering; no actionable merge-blocking risk remains beyond normal checks and review. Sequence Diagram(s)sequenceDiagram
participant 呼び出し元PHP
participant ResourceMethodTypeProvider
participant PHPインデックス
participant ファイル名インデックス
呼び出し元PHP->>ResourceMethodTypeProvider: リソースURIを解決
ResourceMethodTypeProvider->>PHPインデックス: クラス候補を検索
PHPインデックス-->>ResourceMethodTypeProvider: vendor除外済み候補
ResourceMethodTypeProvider->>ファイル名インデックス: 未解決時にファイル名を検索
ファイル名インデックス-->>ResourceMethodTypeProvider: プロジェクト内候補
ResourceMethodTypeProvider-->>呼び出し元PHP: 型またはnullを返却
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Mirrors the vendor guard of bearsunday#49 (bearsunday#49) into the resolver this branch extracted the fallbacks into. An installed BEAR application carries src/Resource/App/*.php of its own, matching both the path suffix and the FQN tail by shape alone, so the index stages could answer a URI with a dependency's class -- and every MCP resource tool reads through this resolver, not only the type provider. The control flow bearsunday#49 also repairs is already correct here: each stage is a private helper and resolveCached() falls through to the next one. No test is added: bearsunday#49 ships ResourceIndexResolutionFixtureTest, which drives ResourceMethodTypeProvider.complete() and therefore this resolver, and it arrives on this branch when master is merged after bearsunday#49 lands.
|
(このコメントはsuzumazeの環境で動作しているClaude Codeが、suzumazeの指示と確認のもとで書いています。) 到達不能の指摘、ありがとうございます。#46で置き換えた ひとつ、#47との相互作用をお知らせします。#47は
これを避けるため、#47側にvendorガードを先に移植しました( なお制御フローの方は、#47の vendorガードのテストは#47側には追加していません。本PRの |
背景
#46 のレビュー中に、
ResourceMethodTypeProviderの URI 解決に到達不能なコードがあることが分かりました。resolveResourceClassは4段の解決戦略を並べていますが、3段目と4段目に到達しません:リソースが URI の示すパスに無いとき、
findFileByRelativePathが null を返して打ち切られます。インデックス経路が動くのは「そのパスにファイルは存在するが PHP クラスを含まない」という狭い場合だけでした。これは戦略の意図と逆です。クラス名やファイル名で引くのは、リソースがプロジェクトルート外にある構成を解決するためのもので、早期 return が弾いていたのはまさにその構成でした。
cf79ae2(2026-06-10)由来で、#46 とは独立した既存の問題です。#46 が置換したgetVirtualFilesByNameはこの到達不能メソッドの中にあり、テストが無かったのもこれが理由です。変更
各戦略を素通りさせる — 見つからなければ次の戦略へ。
resolveResourceClassFromBaseDirとして抽出インデックス経路に vendor ガードを追加 — 到達可能になったことで顕在化するリスクへの対処です。composer で入れた BEAR アプリは
src/Resource/App/*.phpを\Resource\App\Fooで終わる名前空間で持つため、FQN 末尾一致にもパス末尾一致にも形だけで合致します。依存パッケージのリソースに解決してしまうと、ナビゲーションも型推論もそちらへ飛びますFilenameIndex:allScope→projectScope、加えて/vendor/を除外PhpIndex:isInVendor()で除外テスト
ResourceIndexResolutionFixtureTestを新設しました。インデックス経路の検証にはフィクスチャがコンテントルートを持つ必要があり、既存のResourceMethodTypeProviderFixtureTestでそれをやるとProjectUtil.guessProjectDirの返す値が変わって page context 判定が壊れるため、別クラスにしています(理由は Javadoc に記載)。3件とも、対応する修正を外すと落ちることを確認済みです:
resolvesResourceOutsideUriPathThroughClassNameIndexresolvesResourceOutsideUriPathThroughFilenameIndexignoresVendoredResourceSharingTheUriShape2番目は、#46 が置換した
getVirtualFilesByNameを実際に通す唯一の経路です。./gradlew test155件 green。🤖 Generated with Claude Code
Summary by CodeRabbit
改善
vendor/配下のリソースを除外します。テスト