0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

17.5kスターのomp、bun installはBun 1.3.11でも素通りした

0
Last updated at Posted at 2026-07-14

はじめに

ターミナル向けAIコーディングエージェントoh-my-pi（コマンド名: omp）は、2026年7月時点でGitHub Star数17.5kを集めている新興OSSツールです。目玉機能は「hash-anchored edits」——編集対象の行を丸ごと再送信せず、行ごとの短いコンテンツハッシュ（アンカー）を参照してパッチを当てる仕組みで、ホワイトスペース差異による "string not found" エラーを構造的に防ぐ設計になっています。バージョン16.4.8は2026年7月12日にリリースされたばかりで、記事執筆時点(2026年7月)でも活発に更新が続いています。

この記事で学べること

  • bun install -g で新興CLIツールを試す際に見落としやすい落とし穴
  • package.json の engines フィールドを bun がインストール時に検証しない挙動
  • 巨大なミニファイ済みバンドル（12MB超）で構文エラーが起きたときの切り分け方

対象読者

  • 新しいOSS CLIツールを気軽に試したい方
  • bun / npm の engines フィールドの扱いに疑問を持ったことがある方

前提環境

  • OS: Linux（クラウド実行環境）
  • Bun: v1.3.11
  • Node.js: v22.22.2

TL;DR

  • bun install -g @oh-my-pi/pi-coding-agent は警告ゼロで成功する
  • しかし omp --version を実行すると SyntaxError: Unexpected identifier 'z' で即クラッシュする
  • 原因は package.json の "engines": {"bun": ">=1.3.14"} を満たしていなかったこと（手元は1.3.11）
  • bun はインストール時にこの engines 要件を検証・警告しない
  • エラーメッセージからは using 宣言（Explicit Resource Management）が怪しく見えるが、実際にその構文だけを抜き出すと単体では問題なく動く——エラー文面が原因を教えてくれないタイプの罠

やったこと

ステップ1: グローバルインストール

READMEに従い、bun でグローバルインストールしました。

bun install -g @oh-my-pi/pi-coding-agent

installed @oh-my-pi/pi-coding-agent@16.4.8 with binaries:
 - omp

260 packages installed [9.76s]

Blocked 2 postinstalls. Run `bun pm -g untrusted` for details.

onnxruntime-node と protobufjs の2件のpostinstallスクリプトがbunのセキュリティ機構でブロックされましたが、これはbunの既定挙動（未信頼スクリプトの自動実行拒否）で異常ではありません。インストール自体は 警告らしい警告もなく 正常終了しました。

ステップ2: 動作確認で即クラッシュ

omp --version すら通りませんでした。

$ omp --version
...(中略・minifyされた大量のコード片が出力される)...
SyntaxError: Unexpected identifier 'z'
      at <parse> (.../dist/cli.js:138:1)
      at native:11:43
note: missing sourcemaps for .../dist/cli.js
note: consider bundling with '--sourcemap' to get unminified traces

Bun v1.3.11 (Linux x64)

--help でも同じエラーで落ちます。バイナリを実行する前段階（構文解析）で失敗しているため、コマンドライン引数を変えても回避できません。

調査

Node.js でも同じ症状

dist/cli.js を直接 Node.js v22.22.2 で読み込ませても、同じ Unexpected identifier 'z' が発生しました。

$ node /root/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/dist/cli.js --version
...
SyntaxError: Unexpected identifier 'z'
    at compileSourceTextModule (node:internal/modules/esm/utils:346:16)

エラー箇所をバイトオフセットで特定すると、以下のコードに行き着きました（変数名は元コードのミニファイ後のまま）。

async function Tj4(f,W){
  let{input:Y,stderr:q,allowAbort:Z,allowNonZero:$,...J}=W??{},
      K=typeof Y==="string"?Buffer.from(Y):Y,
      X=K===void 0?J:{...J,stdin:K};
  using z=gB1(f,X);
  return await z.wait({stderr:q,allowAbort:Z,allowNonZero:$})
}

using z = ... はExplicit Resource Management（2025年6月にTC39 Stage 4へ昇格したECMAScript仕様。Symbol.dispose を実装したリソースをブロックスコープで自動破棄する構文）です。Stage 4=仕様として承認済みでも各ランタイムの実装状況は別問題で、手元のNode.js v22.22.2はこの構文をまだサポートしておらず、単体で using 宣言を含むファイルを読ませると同じ Unexpected identifier で失敗することを確認しました。

一方Bunは using をサポート済みで、上記コード片をそのままファイルに切り出して bun で実行すると 問題なく動きました。つまり「using 構文そのもの」が原因ではなく、cli.js 全体（22,458行・12.5MB）の中の 別の何か が真因という状況で、エラーメッセージのスニペット表示は手がかりとしてミスリーディングでした。

真因: engines 要件の不一致

package.json を確認すると、実行系の前提条件がはっきり書かれていました。

{
  "version": "16.4.8",
  "engines": { "bun": ">=1.3.14" }
}

手元のBunは 1.3.11。Bun v1.3.11は2026年3月18日リリース、Bun v1.3.14は2026年5月13日リリースで、omp は少なくとも2バージョン新しいBunのビルド出力（バンドラー内部フォーマットやランタイム最適化）に依存していると考えられます。バージョン不足を検証する目的で bun install -g 実行時に engines 由来の警告（npmでいう EBADENGINE 相当）が出るか確認しましたが、bun 1.3.11のグローバルインストールでは出力されませんでした。npmでは engines を満たさないパッケージに警告が出るケースがあるため、この点はツールごとに挙動が異なると理解しておく必要があります。

アップグレードも一筋縄ではいかなかった

原因が判明したので bun upgrade でBun自体を更新しようとしましたが、この検証環境ではGitHub Releasesへの直接アクセスがネットワークポリシーでブロックされており（curl https://github.com/oven-sh/bun/releases/.../bun-linux-x64.zip が403）、公式インストーラー経由のアップグレードは失敗しました。npm経由の bun パッケージも試しましたが、取得されたのはWindows用バイナリ（bun.exe）のみで、Linux用ネイティブバイナリは含まれていませんでした。結果として、この環境では omp を動作可能な状態にするところまでは到達できませんでした。

著者視点の発見ポイント

実際に手を動かして一番驚いたのは、インストールが「成功」と表示された後に、実行できない理由がエラーメッセージからは全く読み取れなかった ことです。SyntaxError: Unexpected identifier 'z' という文面だけを見ると using 構文の互換性問題を疑うのが自然ですが、実際にその部分だけを切り出すとBunでもNode.jsの一部条件でも動作し、原因の特定にミスリードされました。最終的に package.json の engines フィールドを確認して初めてバージョン不一致に気づけたので、新しいCLIツールをインストールしたら、エラーが出る前にまず engines を cat package.json で確認する のが最短ルートだったと言えます。12.5MBのミニファイ済み単一バンドルにはソースマップが同梱されておらず、note: consider bundling with '--sourcemap' という提案もツール利用者側では対応しようがない点も、デバッグの難易度を上げていました。

まとめ

  • bun install -g の成功は「実行できる」ことを保証しない。engines 要件はインストーラーが検証してくれるとは限らない
  • ミニファイされた巨大バンドルの構文エラーは、エラー箇所のコード片だけでは真因にたどり着けないことがある
  • 新興ツールを試すときは、READMEの前提条件（今回は「Bun ≥ 1.3.14」）を先に確認するのが結局一番早い
  • サンドボックス化されたネットワーク環境では、GitHub Releases直配布のバイナリ更新がブロックされるケースがあるため、npmミラー等の代替入手経路もあわせて確認しておくと良い

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?