Tecnología · GUÍA PRÁCTICA
¿npm ETARGET? Pruebe primero el registro, el rango y las versiones publicadas
“No matching version found” puede indicar una versión nunca publicada, un tag o rango sin coincidencia, un registro privado por scope o metadatos antiguos en un mirror. Localice la diferencia antes de borrar caché o lockfile.

Cuando npm informa ETARGET o “No matching version found”, conserve la especificación completa y pruébela contra el registro que npm usó realmente. La evidencia decisiva es quién la pidió, el endpoint, las versiones publicadas y el mapa de dist-tags, no un cambio casual tras borrar caché o lockfile.
Capture la especificación exacta y quién la pide
Copie la línea ETARGET completa antes de cambiar archivos. Anote paquete, versión exacta, rango o tag, versión de npm y si la petición viene de package.json, package-lock.json, un workspace, una plantilla o una dependencia transitiva. Busque el nombre exacto en ambos manifiestos y use el log y el árbol para identificar el padre transitivo.
Consulte el mismo registro que usa npm
Ejecute npm config get registry y revise los registros por scope en npmrc de proyecto, usuario y CI sin imprimir tokens. Contra ese endpoint use npm view <package> versions --json y npm view <package> dist-tags --json. Que una versión aparezca en npmjs.com no demuestra que el registro privado o mirror configurado ya la exponga.
Separe versión exacta, rango y tag
Una petición exacta como 4.2.1 debe estar publicada. Un rango como ^4.2.1 debe coincidir con al menos una versión devuelta. latest, beta o next son dist-tags móviles. Compare la forma solicitada con versions y dist-tags; no confunda un tag de Git, la versión de Node.js o un release de GitHub con una versión npm.
Compruebe prerelease y límites de publicación
En SemVer, 3.0.0-beta.9 tiene menor precedencia que 3.0.0 y no es el mismo identificador. Si el registro solo lista el prerelease, la petición exacta 3.0.0 sigue sin coincidir. Antes de cambiar el rango, revise tiempos y dist-tags y conserve la especificación fallida para separar nunca publicada, retirada o temporalmente ausente.
Audite manifiesto, lockfile y mirror por separado
Si npm view muestra la versión en el mismo registro, compare el entorno CI o IDE que falla: URL, mapeo por scope, proxy y credenciales pueden variar. Localice la petición en package.json y package-lock.json. Para un proxy privado use la actualización admitida por su administrador; no borre lockfile ni fuerce la caché antes de saber qué capa omitió la versión.
Corrija solo la diferencia demostrada
Si la versión nunca existió, ajuste plantilla o dependencia a una versión compatible y pruebe el cambio. Si un dist-tag apunta a otro lugar, use una versión explícita verificada o espere al publicador. Si el mirror está atrasado, actualícelo. Si solo CI difiere, alinee el registro por scope sin revelar credenciales. Repita npm view, instale y revise el diff del lockfile.
