@clerk/upgrade stalls on binary build artifacts

Empieza reproduciendo el bloqueo con bun x @clerk/upgrade --dry-run en el repositorio tauri-plugin-clerk enlazado, comparando ejecuciones con y sin examples/react-example/src-tauri/target/debug. Usa el gist enlazado y la salida del escaneo para localizar el punto de entrada del escaneo. Done debe incluir el manejo de artefactos de compilación binarios sin bloquearse; la ruta del spinner, los globs de exclusión predeterminados y la compatibilidad con .gitignore aparecen como comportamiento adicional u opcional.

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.