VPN이 아니라 패키지 범위로 npm이 레지스트리를 고르게 하자

VPN에 연결한다고 해서 하루에 두 번 npm의 레지스트리 설정을 고쳐야 하는 것은 아닙니다. 프로젝트 수준 구성 파일의 범위 항목은 회사 패키지를 한 레지스트리로, 나머지는 공개 레지스트리로 보낼 수 있으며, 전환도 금요일 오후에 남겨 두는 덮어쓰기도 필요 없습니다. 문제는 이것이 이름 지정만 해결한다는 점으로, 라우팅과 자격 증명과 구성 우선순위는 각자 다른 방식으로 실패하는 세 가지 별개의 문제입니다.

두 이름, 두 목적지

npm 패키지 이름에는 범위가 있거나 없습니다. 범위가 있는 이름은 @ 기호와 범위 식별자로 시작하며, 구성이 매핑할 수 있는 것은 바로 그 식별자입니다. 패키지의 다른 무엇도 매핑에 중요하지 않습니다. 레지스트리는 패키지가 내부인지 공개인지로 요청을 보는 일이 없고, 이름만 봅니다.

따라서 아래 파일은 세 줄로 두 가지 의도를 표현합니다: 공개 패키지는 공개 레지스트리로 가고, 회사 범위 아래의 패키지는 그 호스트용 토큰과 함께 회사 레지스트리로 갑니다.

registry=https://registry.npmjs.org/
@acme:registry=https://packages.corp.example/
//packages.corp.example/:_authToken=${NPM_TOKEN}

범위와 호스트와 변수 이름을 조직이 실제로 제공하는 것으로 바꾸십시오. 중요한 것은 구조이고 예시 값이 아닙니다. 두 줄의 구성이 정책 전체를 담기 때문에 복사하기보다 이해할 가치가 있습니다.

매핑과 네트워크는 머릿속에서 별도의 칸에 두십시오. 범위 항목은 닿지 않는 호스트를 닿게 만들 수 없고, 동작하는 터널은 패키지가 어느 레지스트리에 속하는지 npm에 알려 줄 수 없습니다.

파일을 올바른 순서로 쓰십시오

npm이 여러 파일을 읽더라도 사고에서는 프로젝트 파일을 먼저 두십시오. 프로젝트 디렉터리의 .npmrc 는 동료들이 저장소를 통해 물려받는 파일이므로 개인 토큰이 아니라 공유 정책을 표현해야 합니다. 그 파일은 검토자가 읽을 파일이기도 합니다. 한눈에 검토할 수 있을 만큼 작게 유지하십시오.

조직이 다르게 결정하지 않았다면 기본 registry 줄은 공개 레지스트리를 가리키게 두십시오. 그것을 지우면 머신이 사용자 수준 파일이 말하는 것에 의존하게 되고, 그것이 두 노트북에서 다른 결과를 만드는 바로 그런 암묵적 의존입니다.

범위 줄은 와일드카드가 아닙니다. 범위 밖의 이름은 기본값을 계속 쓰며, 직접 쓰지 않은 모든 의존성에 원하는 동작이 바로 이것입니다.

커밋하기 전에 파일이 무엇으로 해석되는지 확인하되 실제 설치 대신 일회용 패키지 이름을 써서 실수가 아무 비용도 들지 않게 하십시오.

자격 증명은 프로젝트가 아니라 호스트에 속합니다

인증 항목은 레지스트리 호스트에, 레지스트리가 요구하는 경우 경로에도 묶입니다. 토큰 줄이 범위가 아니라 이중 슬래시와 호스트로 시작하는 이유입니다. 그 자리에 호스트가 보이면 줄의 나머지는 더 이상 임의의 문장 부호처럼 보이지 않습니다. 그것은 주소이고, 토큰은 거기에 붙어 있습니다.

환경 변수를 쓰면 리터럴 토큰이 저장소의 파일 밖에 남습니다. 토큰이 어디서나 보이지 않게 되는 것은 아니고, 여전히 프로세스 환경에 나타나며 구성을 출력하는 명령이 그것을 드러낼 수 있습니다.

조직이 승인한 로컬 또는 CI 자격 증명 메커니즘으로 변수를 마련하고, 문서로 복사될 수 있는 예시에 실제 토큰을 절대 붙여 넣지 마십시오.

레지스트리 두 개가 관련되면 각각 자기 항목을 가집니다. 자격을 갖추지 않은 단일 토큰 설정은 좋게는 모호하고 나쁘게는 잘못된 호스트로 전송됩니다.

잘못된 레지스트리가 이길 때

구성은 계층 구조이고, 유효한 값이 방금 편집한 파일의 값과 반드시 같지는 않습니다. 프로젝트 설정, 사용자 설정, 전역 설정, 환경 변수가 모두 참여합니다. 이 계층 때문에 수정이 내 머신에서는 되고 동료의 컨테이너에서는 안 됩니다. 또한 그것에 대해 논쟁하기 전에 유효한 값을 출력할 가치가 있는 이유이기도 합니다.

환경 변수는 작업이 레지스트리를 한 번 설정하면 이후 모든 단계가 그것을 물려받는 CI에서 흔한 범인입니다. 두 번째로 흔한 것은 개발자 머신의 사용자 수준 파일이 저장소가 말하는 것을 덮어쓰는 경우입니다.

다른 무엇을 디버깅하기 전에 범위가 있는 이름과 없는 이름 각각에 대해 유효한 구성과 해석된 레지스트리를 출력하십시오. 그 두 답이 기대와 같다면 문제는 네트워크이고, 아니라면 문제는 구성이며 VPN을 아무리 손봐도 도움이 되지 않습니다.

커밋 전 점검 목록

범위 이름이 실제로 게시된 패키지와 맞는지, 기본 레지스트리가 명시적인지, 토큰 줄이 올바른 호스트를 가리키는지 확인하십시오. 범위의 오타는 패키지가 공개 레지스트리에서 해석되어 같은 이름의 남의 모듈이 돌아오기 때문에 가장 기이한 실패를 만듭니다. 토큰을 디버깅하기 전에 이름을 확인하십시오.

사설 레지스트리에 설치를 실행하는 컨텍스트의 머신에서 닿을 수 있는지 확인하십시오. 브라우저에서만 닿는 것으로는 부족하고, 프록시나 컨테이너가 셸과 다른 라우팅을 가질 때 이 구분이 중요합니다.

그다음 캐시된 패키지가 없는 깨끗한 체크아웃에서 동작을 확인하십시오. 새로 설치하는 것만이 새 동료가 무엇을 겪을지 보여 주는 유일한 시험입니다.