Solicitar uma versão do pacote com repositórios upstream

O exemplo a seguir mostra os cenários possíveis quando um gerenciador de pacotes solicita um pacote de um repositório de CodeCatalyst pacotes que tenha repositórios upstream.

Neste exemplo, um gerenciador de pacotes, comonpm, solicita uma versão de pacote de um repositório de pacotes chamado downstream que tem vários repositórios upstream. Quando o pacote é solicitado, o seguinte pode ocorrer:

• Se downstream contiver a versão do pacote solicitada, ela será devolvida ao cliente.

• Se downstream não contiver a versão do pacote solicitada, CodeCatalyst procurará por ela nos downstream repositórios upstream, na ordem de pesquisa configurada. Se a versão do pacote for encontrada, uma referência a ela será copiada para downstream e a versão do pacote será devolvida ao cliente.

• Se nenhum dos downstream repositórios upstream contiver a versão do pacote, uma Not Found resposta HTTP 404 será retornada ao cliente.

A quantidade máxima de repositórios upstream diretos permitidos para um repositório é dez. O número máximo de CodeCatalyst pesquisas nos repositórios quando uma versão do pacote é solicitada é 25.

Retenção de pacotes de repositórios upstream

Se uma versão de pacote solicitada for encontrada em um repositório upstream, uma referência a ela será retida e estará sempre disponível no repositório que a solicitou. Isso garante que você tenha acesso aos seus pacotes se houver uma interrupção inesperada do repositório upstream. A versão retida do pacote não é afetada por nenhum das seguintes ações:

• Excluir o repositório upstream.

• Desconectar o repositório upstream do repositório downstream.

• Excluir a versão do pacote do repositório upstream.

• Editar a versão do pacote no repositório upstream (por exemplo, adicionar um novo ativo a ele).

Buscando pacotes por meio de um relacionamento upstream

CodeCatalyst pode buscar pacotes por meio de vários repositórios vinculados chamados repositórios upstream. Se um repositório de CodeCatalyst pacotes tiver uma conexão upstream com outro repositório de CodeCatalyst pacotes que tenha uma conexão upstream com um repositório gateway, as solicitações de pacotes que não estão no repositório upstream serão copiadas do repositório externo. Por exemplo, considere a seguinte configuração: um repositório chamado repo-A tem uma conexão upstream com o repositório do gateway,. npm-public-registry-gateway npm-public-registry-gatewaytem uma conexão upstream com o repositório público de pacotes,. https://npmjs.com

Se npm estiver configurado para usar o repo-A repositório, a execução npm install inicia a cópia dos pacotes de https://npmjs.comdentro. npm-public-registry-gateway As versões instaladas também são incorporadas em repo-A. O exemplo a seguir instala o 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

Depois de executadonpm install, repo-A contém somente a versão mais recente (lodash 4.17.20) porque essa é a versão que foi obtida por npm fromrepo-A.

Como npm-public-registry-gateway tem uma conexão upstream externa com https://npmjs.com, todas as versões do pacote importadas https://npmjs.comsão armazenadas emnpm-public-registry-gateway. Essas versões do pacote poderiam ter sido obtidas por qualquer repositório downstream com uma conexão upstream que leva a. npm-public-registry-gateway

O conteúdo de npm-public-registry-gateway fornece uma maneira de você ver todos os pacotes e versões de pacotes importados https://npmjs.comao longo do tempo.

Retenção de pacotes em repositórios intermediários

CodeCatalyst permite que você encadeie repositórios upstream. Por exemplo, repo-A pode ter repo-B como um repositório upstream e repo-B pode ter repo-C como um repositório upstream. Essa configuração faz com que as versões do pacote sejam inseridas no repo-B e repo-C disponíveis do repo-A.

Quando um gerenciador de pacotes se conecta ao repositório repo-A e busca uma versão do pacote no repositóriorepo-C, a versão do pacote não é retida no repositório. repo-B A versão do pacote só é mantida no repositório downstream mais distante, que neste exemplo é. repo-A Ele não é retido em nenhum repositório intermediário. Isso também vale para cadeias mais longas; por exemplo, se houvesse quatro repositórios:repo-A,,repo-B, e repo-Crepo-D, e um gerenciador de pacotes conectado para repo-A obter uma versão do pacoterepo-D, a versão do pacote seria retida em, repo-A mas não em ou. repo-B repo-C

O comportamento de retenção de pacotes é semelhante ao extrair uma versão de pacote de um repositório público de pacotes, exceto que a versão do pacote é sempre retida no repositório do gateway que tem a conexão direta upstream com o repositório público. Por exemplo, repo-A tem repo-B como repositório upstream. repo-Btem npm-public-registry-gateway como um repositório upstream, que tem uma conexão upstream com o repositório público, npmjs.com; veja o diagrama abaixo.

Se um gerenciador de pacotes conectado repo-A solicitar uma versão específica do pacote, lodash 4.17.20, por exemplo, e a versão do pacote não estiver presente em nenhum dos três repositórios, ela será obtida em npmjs.com. Quando o lodash 4.17.20 é obtido, ele é retido, repo-A pois é o repositório mais distante a jusante e npm-public-registry-gateway tem a conexão upstream com o repositório externo público, npmjs.com. lodash 4.17.20 não é retido repo-B porque é um repositório intermediário.