@clerk/upgrade stalls on binary build artifacts

Inizia riproducendo il blocco con bun x @clerk/upgrade --dry-run nel repository tauri-plugin-clerk collegato, confrontando le esecuzioni con e senza examples/react-example/src-tauri/target/debug. Usa il gist collegato e l'output della scansione per individuare il punto di ingresso della scansione. Done dovrebbe includere la gestione degli artefatti binari di build senza bloccarsi; il percorso dello spinner, i glob di esclusione predefiniti e il supporto per .gitignore sono elencati come comportamenti aggiuntivi o opzionali.

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.