公開npmパッケージのCLIが、同梱した非バンドルアセット（テンプレート・スキーマ・別ツールへパスで渡す未コンパイルのソースファイルなど）を実行時に見つける必要がある場合、import.meta.url（CommonJSなら__dirname）のディレクトリから親方向へpackage.jsonを探索し、そのnameフィールドが自パッケージ名と一致するディレクトリを「自分のパッケージルート」として確定する、という汎用パターンが使える。

判断基準

• この方法は、ソースから直接実行する場合（開発時のトランスパイラ実行等）と、npmインストール後にビルド済みファイルから実行される場合（node_modules配下にネストされる場合も含む）の両方で、同一ロジックのまま正しく解決できる。固定の相対パス段数（例:「常に3階層上」）に頼る実装は、実行元がソースかビルド成果物かで階層が変わるため壊れやすい。
• package.jsonが見つかってもnameが自パッケージと一致しない場合は探索を継続する。ネストされたnode_modules内で別パッケージのpackage.jsonに先に当たる可能性があるため、nameの一致確認は必須。
• ルートまで遡っても見つからない場合はエラーとして扱う（無限ループやundefined参照を防ぐ）。

関連する設計判断: アセットをビルド成果物へコピーするか、ソースのまま参照するか

同梱アセットをビルド時にビルド成果物側へコピーして参照する方法（成果物を自己完結させる）に対し、ビルドせずソースディレクトリに置いたまま実行時にパッケージルートからの相対パスで参照する方法もある。後者が有利なのは、そのアセットが別ツール（バンドラー等）へ「ファイルパスとして渡すだけで、自分ではimportしない」入力である場合——コピーを経由すると差分管理の手間が増えるだけで、実行時にパッケージルートさえ分かれば十分な場面では、探索ロジックの方が単純になる。

検証

ビルドしたエントリーファイルをリポジトリ外の空ディレクトリへ実際にインストールし、そこから直接実行してアセット参照が解決できるかを確認する（tarball経由のインストールが最も実運用に近い）。