Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solicitar una versión de paquete con repositorios ascendentes

El siguiente ejemplo muestra los posibles escenarios en los que un administrador de paquetes solicita un paquete de un repositorio de CodeCatalyst paquetes que tiene repositorios ascendentes.

En este ejemplo, un administrador de paquetes, por ejemplonpm, solicita una versión de paquete desde un repositorio de paquetes denominado downstream que tiene varios repositorios ascendentes. Cuando se solicita el paquete, puede ocurrir lo siguiente:

El número máximo de repositorios ascendentes directos permitidos para un repositorio es 10. El número máximo de CodeCatalyst búsquedas en los repositorios cuando se solicita una versión de paquete es de 25.

Retención de paquetes de repositorios ascendentes

Si la versión de un paquete solicitada se encuentra en un repositorio anterior, se conserva una referencia a la misma y siempre está disponible en el repositorio que la solicitó. Esto garantiza que tendrá acceso a sus paquetes en caso de que se produzca una interrupción inesperada del repositorio principal. La versión del paquete retenida no se ve afectada por ninguno de los siguientes factores:

Obtener paquetes a través de una relación ascendente

CodeCatalyst puede buscar paquetes a través de varios repositorios enlazados denominados repositorios ascendentes. Si un repositorio de CodeCatalyst paquetes tiene una conexión ascendente a otro repositorio de CodeCatalyst paquetes que tiene una conexión ascendente a un repositorio de puerta de enlace, las solicitudes de paquetes que no estén en el repositorio ascendente se copian del repositorio externo. Por ejemplo, considere la siguiente configuración: un repositorio denominado repo-A tiene una conexión ascendente con el repositorio de puerta de enlace,. npm-public-registry-gateway npm-public-registry-gatewaytiene una conexión ascendente al repositorio público de paquetes,. https://npmjs.com

Si npm está configurado para usar el repo-A repositorio, la ejecución npm install inicia la copia de los paquetes desde https://npmjs.comdentro. npm-public-registry-gateway También se incluyen las versiones instaladasrepo-A. El siguiente ejemplo instala lodash.

$ npm config get registry
https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s

Tras ejecutarsenpm install, repo-A contiene solo la versión más reciente (lodash 4.17.20) porque es la versión desde la que se obtuvo. npm repo-A

Como npm-public-registry-gateway tiene una conexión ascendente externa a https://npmjs.com, todas las versiones del paquete desde las que se importan se https://npmjs.comalmacenan en ella. npm-public-registry-gateway Estas versiones de paquetes podrían haberse obtenido en cualquier repositorio descendente con una conexión ascendente que conduzca a. npm-public-registry-gateway

El contenido de npm-public-registry-gateway proporciona una forma de ver todos los paquetes y las versiones de los paquetes que se han importado a lo largo del https://npmjs.comtiempo.

Retención de paquetes en repositorios intermedios

CodeCatalyst permite encadenar repositorios ascendentes. Por ejemplo, repo-A puede tener repo-B como repositorio ascendente y repo-B puede tenerlo repo-C como repositorio ascendente. Esta configuración hace que las versiones del paquete en repo-B y repo-C estén disponibles de repo-A.

Cuando un administrador de paquetes se conecta al repositorio repo-A y obtiene una versión del paquete del repositoriorepo-C, la versión del paquete no se conserva en el repositorio. repo-B La versión del paquete solo se conserva en el repositorio descendente más alejado, como ocurre en este ejemplo. repo-A No se conserva en ningún repositorio intermedio. Esto también es válido para cadenas más largas; por ejemplo, si hubiera cuatro repositorios:repo-A,, y, y repo-B repo-Crepo-D, y un administrador de paquetes conectado para repo-A extraer una versión de un paqueterepo-D, la versión del paquete se conservaría en, repo-A pero no en o. repo-B repo-C

El comportamiento de retención de paquetes es similar cuando se extrae una versión de paquete de un repositorio de paquetes público, excepto que la versión del paquete siempre se conserva en el repositorio de puerta de enlace que tiene la conexión ascendente directa con el repositorio público. Por ejemplo, repo-A tiene repo-B como repositorio ascendente. repo-Btiene npm-public-registry-gateway como repositorio ascendente, que tiene una conexión ascendente con el repositorio público npmjs.com; consulte el siguiente diagrama.

Si un administrador de paquetes conectado repo-A solicita una versión de paquete específica, por ejemplo, lodash 4.17.20, y la versión del paquete no está presente en ninguno de los tres repositorios, se obtendrá de npmjs.com. Cuando se obtiene lodash 4.17.20, se conserva porque es el repositorio descendente más alejado y tiene la conexión ascendente con el repositorio externo público, npmjs.com. repo-A npm-public-registry-gateway lodash 4.17.20 no se conserva porque se trata de un repositorio intermedio. repo-B