@clerk/upgrade stalls on binary build artifacts

リンクされた tauri-plugin-clerk リポジトリで bun x @clerk/upgrade --dry-run を使って停止を再現することから始め、examples/react-example/src-tauri/target/debug の有無で実行結果を比較します。リンクされた gist とスキャン出力を使って、スキャンのエントリーポイントを特定します。Done には、停止せずにバイナリのビルド成果物を処理することを含める必要があります。spinner のパス、デフォルトの ignore glob、および .gitignore のサポートは、追加またはオプションの動作として記載されています。

Preliminary Checks

• I have reviewed the documentation: https://clerk.com/docs

• I have searched for existing issues: https://github.com/clerk/javascript/issues

• I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

• This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction

https://gist.github.com/rofinn/34747e70ad8ecadd03f76d0d4200dfd9

Publishable key

N/A

Description

Running clerk/upgrade --dry-run in a monorepo containing cargo build artifacts causes the scan step to stall trying to analyze binary build files. The linked github gist includes the steps to reproduce with shell output.

Steps to reproduce:

1. Clone https://github.com/Nipsuli/tauri-plugin-clerk.git (or any repo that may produced binary build artifacts)
2. Generated the build artifacts. In the example, this was running cargo build in examples/react-example/src-tauri.
3. Run time bun x @clerk/upgrade --dry-run from the examples/react-example directory (to mimic a monorepo).
4. Kill the scan after it stalls
5. Delete the examples/react-example/src-tauri/target/debug directory and rerun
6. You'll notice it completes fine.

Expected behavior:

I would have expected the scanning step to focus on text files that contain potential code issues. I understand that just relying on extensions isn't the most reliable if you want to catch issues in scripts or markdown files, but I think it should be able to identify and catch binary build artifacts.

Actual behavior:

I think the desired behaviour has 4 components.

1. The scan file spinner should probably give the full relative path to make it easier to spot when this is happening. Some build artifacts can have pretty opaque names.
2. I think we should be able to detect binary files as part of the scan.
3. (Optional) Broaden the default ignore globs include include common build output directories
4. (Optional) It'd be nice if the scanner picked up existing .gitignore rules

Environment

N/A. Can be reproduced in any repo with binary build artifacts.