REA のバージョン比較：更新で何が変わった？

01. 不具合を具体的にする

「更新でエクスポートが壊れた」では推測の余地が大きすぎます。入力、操作、差を記録してください。例えば、引用符を含むタイトルが更新前は正しく出力され、更新後は不正な CSV 行になる、という形です。

アプリの2バージョンを別フォルダーに置き、リリース名とファイルのハッシュを記録します。同種の配布物を比較してください。開発用ソースツリーと本番用の圧縮済みバンドルは、同じ種類の根拠ではありません。

npx -y [email protected] analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y [email protected] analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. 保存した解析結果を比較する

元の JSON 出力を完全な形で残します。比較処理が必要とするのは、真正性を検証できるアプリ解析結果です。手編集の要約やファイル名一覧では代用できません。

接続したエージェントに、利用可能な compare_application_versions のスキーマを確認させ、それに従って二つの結果を渡します。リリースで変わりうる入れ子の入力項目を推測せずに済みます。同じ仕様は CLI でも確認できます。

npx -y [email protected] compare-application-versions --schema

before.json と after.json の完全なアプリ解析結果を使い、REA の compare_application_versions を実行してください。先にインストール済みツールのスキーマを確認します。CSV エクスポートに絞り、変更モジュール、関連する呼び出し経路、未解決の対応関係を報告してください。部分的なカバレッジでノードがないことを、削除の証拠と解釈しないでください。

03. 短縮された名前ではなく機能を比較する

既知のボタン、IPC チャネル、整形処理を起点にします。両バージョンで同じ機能を追い、変更コードを調べます。圧縮された変数名は、動作が同じでも再ビルドで変わることがよくあります。

モジュールのダイジェストは完全な同一性を示せますが、関数名やバンドルのチャンク番号が変わっただけでは意味上の変更を示せません。対応が取れない部分や一部しか解析できていない領域を報告に残します。

• 両バージョンに該当機能の入口があるか？
• ソースのどの領域が実際に異なるか？
• 変更された分岐は失敗する入力に影響するか？
• パッケージ化、設定、解析範囲の不足で差を説明できないか？

04. 両バージョンで同じ入力を試す

使い捨てのデータフォルダーを別々に用意し、新版の起動で旧版のテスト状態が移行されないようにします。同じテスト内容に全く同じ操作を行い、各実行の出力ファイルか対象動作の記録を保存します。

CSV の回帰不具合なら、出力行を解析してフィールドを比較します。改行コードなどのバイト差も重要ですが、タイムスタンプの変更が引用符処理の失敗を埋もれさせないようにします。比較に使った正規化はすべて記録してください。

観測した入力そのものを使う回帰テストを作ってください。新旧の出力を解析し、エクスポートされたフィールドを比較します。生の差分と正規化後の比較を両方示し、原因と疑うソース変更と、実際に再現した動作を区別してください。

05. 役に立つ不具合報告を書く

2バージョンの識別情報、失敗する入力一つ、正確な再現手順、観測した新旧の出力、最小限の関連ソース差分を含めます。動作を再現したのか、静的コードから予測しただけなのかも明記してください。

良い比較は、回帰テスト、互換性の回避策、小さな代替実装など、次の行動につながります。このチュートリアルは手順の説明であり、特定の商用リリースに回帰不具合があると主張するものではありません。