Watch at EaseHistorias. Respuestas. Perspectiva.

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.

Ilustración original de una petición que llega al registro y se divide entre versión disponible, etiquetada y ausente.
Ilustración original: consulte el registro efectivo antes de cambiar la dependencia. Watch at Ease

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.

Ilustración original que compara manifiesto y lockfile con metadatos actuales y antiguos.
Ilustración original: separe la especificación, el conjunto de versiones y el endpoint. Watch at Ease