Documentación / Referencia / Qué escanea

Qué escanea

Un diagnóstico lee manifiestos y lockfiles. No evalúa el código fuente. migrate también lista hasta 20 líneas de import de paquetes heredados, con la misma profundidad y los mismos directorios omitidos.

Cargo.toml

Busca el crate soroban-sdk en estas formas:

toml

# string
soroban-sdk = "21.0.0"

# table
soroban-sdk = { version = "21.0.0", features = ["testutils"] }

# renamed
sdk = { package = "soroban-sdk", version = "21.0.0" }

# workspace
[workspace.dependencies]
soroban-sdk = "21.0.0"

[dependencies]
soroban-sdk = { workspace = true }

Tablas que lee: [dependencies], [dev-dependencies], [build-dependencies] y las mismas tres dentro de [target.<cfg>].
Renombres: una clave package = "soroban-sdk" se sigue hasta el nombre real del crate.
Workspaces: un miembro con workspace = true toma su versión del manifiesto ancestro más cercano que declara la misma clave en [workspace.dependencies]. Una dependencia del workspace que ningún miembro usa igual se reporta, en el manifiesto del workspace. Si una dependencia con workspace = true no se puede resolver, se reporta sin versión, lo que da SDK_UNKNOWN.
Duplicados: los hallazgos idénticos (mismo archivo, crate y versión) se reportan una sola vez.

package.json

Lee solo dependencies y devDependencies, para estos paquetes:

@stellar/stellar-sdk
@stellar/stellar-base
soroban-client (heredado)
stellar-sdk (heredado, sin scope)

No lee las dependencias peer ni las opcionales.

Alias de npm

Un miembro que usa un alias npm: se lee como el paquete real que hay detrás. Este es el SDK actual, no el stellar-sdk heredado:

package.json

"stellar-sdk": "npm:@stellar/stellar-sdk@17.4.0"

La versión que sigue al último @ se lee como siempre. Un alias sin versión (npm:@stellar/stellar-sdk) es desconocido. Este caso apareció en un manifiesto real (stellar/freighter) al armar el corpus de lockfiles. Consulta Modo de migración para ver cómo se editan los alias.

Dónde busca

Recorre la ruta que le indicas, en orden alfabético, hasta cuatro carpetas de profundidad.
Omite node_modules, target, dist, .git, .next, vendor, build y coverage.
Las carpetas y los archivos ilegibles, y los manifiestos que no se pueden analizar, se reportan como MANIFEST_UNPARSEABLE en lugar de ignorarse.

Cómo se leen las versiones

kedgeway necesita un único major para comparar. Quita los operadores de rango del inicio y lee el major de lo que queda.

Declarada	Se lee como
`21.0.0`, `^21.0.0`, `~21.0`	major 21
`>=21.0.0`	major 21 (se quita el `>=`)
`21.x`	major 21
`<22`, `<=21.0.0`	desconocida: un límite superior por sí solo no identifica un major
`>=20 \|\| ^21`	desconocida: los rangos compuestos no se resuelven
vacía, `*`, una fuente git o de ruta	desconocida

Una versión desconocida produce SDK_UNKNOWN o JS_SDK_UNKNOWN, nunca una suposición.

Cuando un lockfile resuelve la dependencia, se usa esa versión exacta y esta tabla solo importa como respaldo. Cuando un rango de JS se compara con versiones candidatas, kedgeway usa el paquete semver, así que los rangos con guion, ||, los rangos x y las reglas de prerelease se comportan como en npm. Los requisitos de Cargo usan un comparador propio de kedgeway: un 1.2.3 sin prefijo equivale a ^1.2.3, y entiende *, = y las combinaciones >=, <.

Lockfiles

Un rango de manifiesto como ^21 dice poco sobre lo que compilas. Cuando existe un lockfile, kedgeway reporta la versión resuelta de cada dependencia detectada y compara esa en lugar de la versión del manifiesto. La evidencia indica cuál usó, por ejemplo resolved 21.7.6 from Cargo.lock; manifest ^21.

Lockfile	Cómo se encuentra la dependencia directa
`Cargo.lock`	Entre las entradas del crate, la que tiene una versión que cumple el requisito del manifiesto (reglas de Cargo). Si ninguna lo cumple, o lo cumplen varias, la dependencia queda sin resolver y la evidencia dice `ambiguous in Cargo.lock`.
`package-lock.json`	`packages["node_modules/<name>"]` (v2 y v3) o, si no, `dependencies[<name>]` (v1).
`pnpm-lock.yaml`	La entrada propia del importer (la raíz o el miembro del workspace) o, si no, la única versión del paquete que cumple el rango del manifiesto. Si hay varias candidatas, se reporta como ambiguo. Versiones de lockfile de la 5 a la 9, con un parser mínimo.
`yarn.lock`	El bloque cuyo descriptor es `name@<manifest range>` (classic) o `name@npm:<range>` (berry). Parser mínimo.

Ambiguo significa respaldo. Cuando un lockfile no puede dar una sola respuesta, kedgeway usa la versión del manifiesto y lo indica en la evidencia. Nunca adivina.
Dónde busca. El lockfile más cercano, subiendo desde la carpeta del manifiesto hasta la raíz del escaneo, que tenga un resultado para esa dependencia. Nunca lee por encima de la raíz del escaneo. Si hay un lockfile más arriba, el reporte de texto imprime un hint:.
Los rangos que no fijan un major (como <21) dejan de ser desconocidos cuando un lockfile fija la dependencia.
Límites. Solo se leen estos cuatro lockfiles. Las estructuras poco comunes de pnpm o yarn no resuelven nada y recurren al manifiesto. Las etiquetas de prerelease se ignoran al comparar una versión con un requisito de Cargo.
Probado con archivos reales. Los parsers se ejecutan contra siete lockfiles reales de repositorios públicos (Cargo.lock v4, package-lock v3, pnpm-lock v9, yarn classic y berry). Los repositorios y commits están listados en fixtures/lockfiles/SOURCES.md en el repo de kedgeway.

Repositorios remotos

diagnose y migrate pueden escanear un repositorio que no clonaste. Pasa una URL de git u owner/repo en lugar de una ruta. Consulta Comandos para ver las formas aceptadas y --ref.

Cómo lo obtiene. kedgeway ejecuta git clone --depth 1 --single-branch --no-tags en un directorio temporal privado, lo escanea y luego lo borra, también cuando el escaneo falla. No se ejecuta nada del repositorio.
Repositorios privados. Las credenciales de git ya tienen que estar configuradas, mediante un agente SSH o un credential helper. kedgeway nunca las pide ni las guarda.
Sin git. Para repositorios de GitHub, kedgeway descarga el tarball del código y lo descomprime solo con Node, con un máximo de 50 MB y 20,000 entradas.
Rechazados. file:// y cualquier otro esquema, las URL con credenciales incluidas y las refs inseguras terminan con 1.
Salida. El encabezado del reporte muestra github.com/o/r@main en lugar de la ruta temporal. Las rutas de los hallazgos, de SARIF y de las anotaciones siguen siendo relativas a la raíz del repositorio.
Migrate. Un migrate remoto es solo un dry run.

Terminal

kedgeway diagnose https://github.com/o/r
kedgeway diagnose o/r --ref v1.2.0

Verificaciones del toolchain

Además de los SDK, kedgeway lee el toolchain que fija el repo. Cada hallazgo apunta a un archivo y una línea.

Versiones fijadas de Stellar CLI. Se leen de los workflows (cargo install ... --version X, stellar-cli@X y el input version: de la action stellar/stellar-cli), Dockerfile*, Makefile, los scripts de shell en la raíz y en scripts/, .tool-versions y @stellar/stellar-cli en package.json. Cada versión fijada se compara por major con la versión de Stellar CLI de la página oficial Software Versions. No se reporta nada si el repo no fija ninguna.
Target de Rust. Si un repo con soroban-sdk declara wasm32-unknown-unknown (rust-toolchain.toml, .cargo/config.toml, workflows, Makefiles, scripts) y nunca wasm32v1-none, RUST_TARGET_LEGACY te indica que ejecutes rustup target add wasm32v1-none.
Toolchain de Rust. Un canal de Rust fijado por debajo de 1.84.0 genera RUST_TOOLCHAIN_OLD, porque la guía de configuración requiere Rust v1.84.0 o más reciente. stable y nightly no cuentan como versiones fijadas.