npm 가이드: Node.js 패키지 관리자

JavaScript는 웹 사이트 및 웹 응용 프로그램 개발과 관련하여 가장 쉽게 사용되는 언어입니다. 수많은 리소스는 놀랍고 더욱이 사용 가능한 라이브러리의 수도 많습니다.

처음에는 이러한 라이브러리가 적고 유지 관리가 쉽습니다. 그러나 곧 종속성 지옥이 시작되고 보다 성숙한 솔루션이 필요합니다.

노드 패키지 관리자(npm)를 입력하세요. JavaScript 패키지 관리자는 Node.js와 함께 가장 많이 사용되지만 독립적으로 사용할 수도 있습니다. 프로젝트의 종속성에 대한 탁월한 제어를 제공하고 오픈 소스 세계에 기여할 수 있는 훌륭한 방법을 제공합니다.

간단히 npm install <package name> 을 실행하고 JavaScript 파일에 삽입하여 시작할 수 있습니다.

특정 버전을 설치하시겠습니까? 문제 없어요. npm install <package name>@1.2.3 을 실행합니다.

Mocha 또는 Angular-CLI와 같은 패키지를 전역적으로 설치하고 싶으십니까? 다음과 같이 -g 를 추가하면 됩니다. npm install -g angular-cli mocha .

분명히 대부분의 사용 사례는 npm 설치에서 멈추고 다른 것이 필요하지 않습니다. 그러나 npm에는 많은 추가 기능이 있습니다. 이 기능은 제가 필수, 정말 유용하거나 그냥 훌륭하다고 생각하는 기능을 강조하여 설명하겠습니다.

CLI 명령

CLI는 사용자가 npm과 상호 작용하는 데 대부분의 시간을 보내는 곳이며 도움말 인터페이스는 실제로 도움이 됩니다.

쿼리 도움말( npm help )은 전체 옵션 배열을 표시하고 npm help-search <searchText> 를 실행하면 npm 마크다운에서 직접 검색 결과 목록이 제공됩니다.

다음은 눈에 띄는 핵심 명령입니다.

• install : npm으로 작업할 때 반드시 필요하기 때문에 여기에 언급되었습니다. 새 패키지를 로컬 또는 전역으로 설치( -g 추가 시)하거나 package.json 파일(나중에 자세히 설명)에 나열된 종속성을 설치하는 데 사용됩니다.

• uninstall : 이것도 필수입니다. node_modules 디렉토리에서 로컬 또는 전역으로( -g 추가 시) 특정 패키지를 제거하는 데 사용됩니다.

• access : 이것은 컨텍스트 npm-organizations 및 범위가 지정된(비공개) 패키지 내에서 npm 사용자 권한 관리자의 놀이터입니다. 정말 강력한 물건입니다. adduser , owner , team 등과 함께 사용하면 누가 무엇에 액세스할 수 있는지 세부적으로 제어할 수 있습니다.

• bin : 패키지는 도대체 어디에 설치되어 있습니까? 절대 파일 경로를 보려면 이 명령을 실행하십시오.

• cache : npm 왼쪽, 오른쪽, 가운데에서 패키지 설치를 시작한다면 이 명령어가 상당히 유용합니다. 로컬로 캐시된 패키지 목록을 보려면 ls 하위 명령으로 호출하거나 캐시에 있는 모든 패키지를 지우려면 clean 하위 명령으로 호출하십시오. npm 레지스트리가 여전히 약간 불안정했을 때 안정적인 환경으로 돌아가거나 npm 권한을 제대로 설정하지 않았을 때 항목을 재설정하는 데 이것이 필수적이었습니다.

• config : 나중에 다른 구성 옵션에 대해 설명하겠지만 이 명령은 주로 set , get 또는 delete 하위 명령을 사용하여 로컬 또는 전역 구성 파일에서 구성 속성을 유지하는 것을 다룹니다.

• dedupe 또는 ddp : 장기간에 걸쳐 프로젝트 작업을 하고 npm에서 바로 패키지를 설치할 때 이 명령은 로컬 패키지 트리를 탐색하고 종속성을 단순화하려고 시도합니다.

• link : 고유한 npm 패키지를 개발할 때 전역 컨텍스트에 대한 심볼릭 링크를 만들 수 있으므로 npm 레지스트리에서 전역적으로 설치된 것처럼 테스트할 수 있습니다. 예를 들어, CLI가 전역적으로 설치된 노드에서 어셈블리 도구를 작성하는 경우 먼저 배포할 필요 없이 이 명령을 실행하고 CLI의 동작을 테스트할 수 있습니다.

• ls : 패키지 종속성과 종속성을 트리 구조로 시각화하는 데 사용됩니다. 보기도 좋고 다른 프로젝트와 비교할 때도 유용합니다.

• outdated : 설치된 종속성의 현재 상태와 오래된 종속성 여부를 평가하는 데 사용됩니다. 루트 종속성 목록이 수백 줄인 프로젝트에서는 패키지를 수동으로 확인하는 것이 거의 불가능합니다. 이 명령에 -g --depth=0 을 추가하면 전역적으로 설치된 패키지도 확인할 수 있습니다.

• publish : 이 명령은 npm용 패키지를 개발할 때 필수적입니다. 이름에서 알 수 있듯이 정확히 작동합니다. 패키지를 npm 레지스트리에 게시합니다.

• search : 세 번째 인수에 제공된 텍스트를 포함하는 모든 패키지에 대한 레지스트리를 검색하려면 이것을 사용하십시오.

• shrinkwrap : 간단히 말해서 이 명령을 사용하면 패키지의 특정 종속성 버전을 순서대로 잠글 수 있으므로 완화된 semver(의미론적 버전 관리) 번호가 프로덕션 코드를 손상시키지 않습니다.

• star : 사용하고 있는 패키지가 정말 마음에 드시나요? 이 명령을 사용하여 터미널에서 직접 감사를 표시한 다음 npm 레지스트리의 패키지 페이지에 반영합니다.

• update : 이것은 일반적으로 오래된 패키지를 업데이트하기 위해 outdated 명령을 따릅니다.

• version : 이것은 package.json 버전 속성을 범프하고 git 태그를 모두 하나로 수행할 수 있는 축약형을 제공합니다.

이러한 명령의 대부분은 하위 명령 및/또는 구성을 사용할 수 있으며 이 목록은 CLI에 대한 완전한 논의가 결코 아닙니다.

npm 구성

구성은 npm의 주요 부분이며 구성 변수를 설정할 수 있는 여러 가지 방법이 있습니다.

CLI 및 환경 변수를 통한 구성

먼저 터미널에서 CLI를 통해 구성을 설정할 수 있습니다.

일반적으로 npm <command> --<configuration option> [<optional value>] 와 같이 표시됩니다.

값을 지정하지 않으면 기본적으로 옵션이 true로 설정됩니다.

예를 들어 범위가 지정된(개인) npm 패키지에서 작업 중이고 이를 공개 패키지로 게시하기로 결정했다고 가정해 보겠습니다.

이는 publish 명령에 --access=public 을 추가하여 쉽게 수행할 수 있습니다. 속성을 공개로 지정하지 않으면 기본값이 제한됩니다(비공개).

이와 같이 다른 명령에 추가된 구성은 모든 곳에서 지속되지 않으므로 CLI를 통해 구성 배열을 설정하는 것이 번거로울 수 있습니다.

이러한 경우 환경 변수를 사용하여 구성을 설정하는 것이 좋습니다.

npm_config_ 접두사로 설정된 모든 환경 변수는 npm을 구성하는 데 사용됩니다.

예: export npm_config_registry=localhost:4321 은 레지스트리 구성 옵션을 전역적으로 설정하고 npm이 실행될 때 포트 4321의 localhost에 있는 npm 레지스트리를 사용합니다.

npmrc 파일을 통한 구성

요구 사항에 따라 다양한 수준으로 설정할 수 있는 특수 .npmrc 파일을 사용하여 구성 옵션을 설정할 수도 있습니다.

• 프로젝트 수준: package.json 파일과 함께 프로젝트 코드의 루트, 일반적으로 path/to/project/.npmrc
• 사용자 수준: 특정 사용자의 계정을 구성하는 디렉터리(일반적으로 ~/.npmrc
• 전역 수준: npm이 전역 구성을 찾는 디렉토리, 일반적으로 $PREFIX/etc/npmrc
• 내장 레벨: 주의하십시오. 이 구성은 전역적일 뿐만 아니라 npm 소스 코드의 일부이기도 하며 모범 사례에서는 유지 관리에 대한 책임이 없는 코드를 변경하지 않을 것을 권장합니다(실제로 요구됨). 일반적으로 /path/to/npm/npmrc 에서 찾을 수 있습니다.

.npmrc 파일의 구성 설정은 npm config set <key> <value> 형식의 명령을 실행하여 CLI를 사용하여 수정하고 유지할 수 있습니다.

예를 들어 npm config set access public 을 실행하여 범위가 지정된(비공개) 패키지의 게시 구성을 영구적으로 공개할 수 있습니다.

기본적으로 이 명령은 구성을 로컬로 유지하지만(위에 설명된 대로 사용자 수준 구성) -g 를 추가하여 전역적으로 유지할 수 있습니다.

지속 구성이 프로젝트 수준 또는 기본 제공 수준에서 발생해야 하는 경우 텍스트 편집기를 사용하여 .npmrc 파일을 수정해야 합니다.

package.json을 통한 구성

마지막으로 package.json 파일에서 구성을 설정할 수 있습니다. 그러나 이것은 거의 사용되지 않습니다(명시적으로 필요한 경우에만 사용해야 함). 프로젝트 수준 .npmrc 파일이 패키지 구성을 설정하는 데 일반적으로 선호되는 위치이기 때문입니다.

주목할만한 구성 설정

• access : 위에서 설명한 것처럼 권한을 설정하는 데 사용됩니다.

• always-auth : 이 설정의 기본값은 false입니다. true로 설정하면 npm은 레지스트리에 연결할 때 항상 인증을 요구합니다.

• ca : 기본값은 npm 인증 기관(CA)입니다. 알려진 등록 대행자에게만 액세스를 허용하려면 null로 변경하거나 해당 특정 등록자에게만 액세스 권한을 부여하려면 특정 CA 인증서에 대해 변경할 수 있습니다. 이 설정은 cafile , cert 및 strict-ssl 과 함께 거의 사용되지 않지만 npm의 보안 및 안정성 측면에 대해 이야기하므로 설치하려는 패키지가 예상한 소스에서 제공된다는 사실을 알고 안심할 수 있습니다.

• color : 기본값은 true로, tty 파일 설명자가 허용하는 stdout 에 색상을 지정하여 터미널의 표준적인 황량함에서 벗어날 수 있습니다. false로 설정하면 터미널이 둔한 상태로 유지됩니다. 항상 으로 설정하면 always 컬러로 출력됩니다.

• depth : 이 설정을 사용하면 실행 깊이를 지정하여 ls 및 outdated 와 같은 재귀 명령으로 표시되는 내용을 세부적으로 제어할 수 있습니다. 값 0은 종속성의 첫 번째 수준만 평가하는 반면 무한대(기본값)는 모든 수준의 종속성을 평가하게 합니다. 이 규칙의 예외는 outdated 것과 함께 사용할 때입니다. 이 경우 더 관련성이 높은 출력을 보장하기 위해 무한대가 0으로 해석됩니다.

• dev : 기본적으로 false로 설정되어 있지만 true로 설정하면( npm install 수행 시) package.json 파일의 모든 개발 종속성이 일반 종속성과 함께 설치됩니다.

• dry-run : 이 설정이 true로 설정되면 npm은 패키지를 변경하지 않고 대신 수행했을 작업을 알려줍니다. 이는 dedupe 또는 update 와 같은 특정 명령을 실행할 때 매우 유용할 수 있습니다.

  

• git-tag-version : 기본적으로 true로 설정되어 있습니다. 이 설정은 npm version 명령을 실행할 때 git의 버전에 태그를 지정합니다. git에 태그가 지정된 버전이 있는 대규모 프로젝트의 패키지 관리자로 npm을 사용하는 경우 시간을 절약하고 package.json 파일을 업데이트하는 것을 잊지 마십시오.

• loglevel : 기본적으로 npm 명령을 실행할 때 오류 및 경고 출력을 제공하는 warn 으로 설정됩니다. 다른 설정에는 출력을 제공하지 않는 silent 가 포함됩니다. error , 출력에 오류만 기록합니다. http 요청 오류만 알리는 http; info , 정보 출력을 원함); 거의 모든 것을 기록하는 verbose ; 그리고 이름에서 알 수 있듯이 silly 양의 출력을 제공한 다음 일부를 제공합니다.

• production : true로 설정하면 npm이 그에 따라 작동하고 프로덕션 모드에서 모든 명령을 실행합니다. 즉, 개발 또는 선택적 종속성이 설치되지 않으며 개발 관련 작업도 실행되지 않습니다.

• rollback : true로 설정하면 실패한 모든 설치가 제거됩니다. 이것은 종속성 설치가 실패할 때 유용합니다. 로깅 수준에 따라 실패한 설치를 확인하고 이를 기록하고 롤백 옵션을 true로 설정하여 npm install 명령을 실행할 수 있어야 합니다. 그런 다음 위에서 설명한 대로 메모와 테스트 실행 설치를 사용하여 문제를 디버깅할 수 있습니다.

• save : When installing a package directly from the registry, you can append -save를 명령에 추가하면 설치된 패키지를 package.json file. For example, to the command which will add the installed package to the dependencies option in the 수 있습니다. file. For example, npm install lodash`는 종속 항목에 lodash를 추가합니다.

• save-dev : 설정 저장 옵션과 유사하게 패키지 설치 시 --save-dev 를 추가하면 package.json 파일의 devDependencies 옵션에 추가됩니다.

• save-optional : 설정 저장 옵션과 유사하게 패키지 설치 시 --save-optional 을 추가하면 package.json 파일의 optionalDependencies 옵션에 추가됩니다.

• save-exact : 패키지를 설치할 때 save , save-dev 및 save-optional 옵션은 설치된 패키지를 semver 범위 연산자를 사용하여 해당 속성에 삽입하여 package.json 파일을 수정합니다. 위에서 언급한 설정 중 하나와 함께 true 값으로 '정확히 저장' 구성 설정을 호출하면 semver 범위를 무시하고 특정 버전 번호가 사용됩니다.

• save-prefix : 이것은 save , save-dev 또는 save-optional 을 사용할 때 semver 범위 연산자를 설정합니다. 기본값은 ^ 이며 설치 시 패키지에 대한 마이너 업그레이드를 허용합니다. 유효한 접두사 semver 범위 연산자로 설정할 수 있습니다.

• tag-version-prefix : 일반적인 기본값은 v 이며, npm version 을 실행할 때 git 태그 버전 앞에 추가할 내용을 지정합니다.

npm을 사용하여 npm 업데이트

npm을 사용하여 자체 업데이트할 수도 있습니다.

npm install -g npm@latest 를 실행하기만 하면 npm이 최신 안정 릴리스로 업데이트됩니다. Node.js의 각 버전은 특정 버전의 npm과 함께 제공된다는 점에 유의하는 것이 중요합니다. 제 경험상 해당 쌍을 너무 복잡하게 만들어서는 안 됩니다.

하루가 끝나면 의도한 대로 페어링을 유지하는 것이 좋습니다.

npm을 독립 실행형 도구로 사용할 때 선택한 버전을 사용하는 것의 의미를 이해해야 합니다. nvm이라는 동일한 시스템에서 다양한 Node.js 버전(및 npm 버전)을 관리하기 위한 훌륭한 도구가 있습니다.

package.json 파일

package.json 파일은 모든 것을 연결하는 중요한 요소입니다.

npm 레지스트리에 패키지를 게시하기 위한 요구 사항이며 종속성의 관리 부분이 활성화되는 곳입니다.

여기에는 "이름"과 "버전"이라는 두 개의 필수 필드가 있으며 이러한 속성은 함께 고유 식별자여야 합니다.

이름 필드는 이름 지정에 대한 npm 문서에 정의된 대로 특정 규칙을 따라야 하며 버전 필드는 semver 사양을 따릅니다.

그 외에도 1마일 길이의 종속성 목록을 가질 수 있으며 semver 버전 및 범위 연산자를 사용하여 각각에 사용할 특정 버전을 정의할 수 있습니다. 다음은 다른 주목할만한 속성 목록입니다.

"기본"

"main"은 애플리케이션의 진입점을 정의하며 기본값은 index.js 입니다. 규칙이나 프레임워크에 따라 app.js 또는 main.js 일 수 있습니다. 물론 원하는 대로 만들 수 있습니다.

"스크립트"

과소평가된 부동산입니다.

첫째, 사전 게시에서 작업을 수행하는 데 사용할 수 있습니다.

둘째, 빌드 작업(gulp 또는 grunt로 정의됨), 다른 종속성 설치 트리거(bower와 같은 것으로), 웹팩으로 개발 서버 시작 또는 일련의 bash 명령을 실행합니다.

"의존성"

이 속성은 호환되는 semver 번호와 함께 애플리케이션에 필요한 패키지 목록입니다. 로컬 패키지를 설치할 때 터미널에서 수정할 수 있기 때문에 주목할만한 속성입니다.

이것은 npm install 명령 끝에 --save (또는 약어 -S )를 추가하여 수행됩니다.

이렇게 하면 새로 설치한 패키지가 package.json 파일의 종속성 목록에 추가됩니다.

마찬가지로 npm uninstall 명령을 실행할 때 --save 를 추가하여 종속성을 제거할 수도 있습니다.

각 종속성의 semver 버전 지정 패턴과 의미를 아는 것이 중요합니다.

semver 규칙이 너무 엄격하면 새로운 기능과 개선 사항을 잃게 되는 반면, semver 규칙이 너무 느슨하면 패키지의 주요 버전이 라인을 따라 설치될 수 있습니다.

깨진 패키지 설치는 특히 패키지의 축소 버전을 사용할 때 해결하기가 상당히 어려울 수 있습니다.

"개발 종속성"

종속성 속성과 별도로 "devDependencies" 속성을 사용하면 개발 단계에서만 사용되며 프로덕션 빌드(예: ESLint, grunt-contrib 패키지 및 Protractor)에 필요하지 않은 종속성을 정의할 수 있습니다. 종속성과 마찬가지로 이 속성은 npm install 명령 또는 npm uninstall 명령 끝에 --save-dev (또는 약어 -D )를 추가하여 터미널에서 수정할 수 있습니다. 종속성에서 언급한 것과 동일한 주의가 버전 관리에 적용됩니다.

"큰 상자"

여기에서 CLI 유틸리티의 경로와 같이 패키지의 실행 파일을 지정할 수 있습니다. 이 속성은 패키지가 설치될 때 실행 파일에 대한 로컬 또는 전역 심볼릭 링크를 생성하도록 npm에 지시합니다.

"구성"

앞에서 설명한 것처럼 여기에서 package.json 파일을 통해 구성 설정을 정의합니다.

"사적인"

true로 설정하면 npm은 패키지 게시를 거부합니다.

이것은 액세스 구성 설정과 혼동되어서는 안 됩니다.

이것은 package.json 과 함께 npm을 활용하는 프로젝트가 있지만 범위가 지정되거나 공개되지 않은 npm 레지스트리에 게시할 의도가 아닌 경우에 편리한 설정입니다.

의도가 변경되면 설정을 false로 변경하기만 하면 패키지를 게시할 수 있습니다.

사용자 정의 속성

package.json 파일은 이름이 이미 정의되거나 예약되지 않은 한 사용자 지정 속성도 허용합니다.

나만의 npm 패키지 개발

npm 생태계는 전 세계 수천 명의 다양한 개발자가 작성한 패키지로 가득 차 있습니다. 각각은 일종의 문제를 해결하고 추상화를 제공하거나 무언가의 구현을 제시합니다.

언젠가는 여러분도 공유할 패키지를 개발하고 싶을 것입니다.

먼저 "name" 및 "version"의 최소 필수 속성을 사용하여 package.json 파일을 작성한 다음 "main" 속성을 작성하여 진입점을 지정해야 합니다(예: index.js).

index.js 파일에 코드를 작성하거나 npm 사용자 계정으로 로그인하거나 터미널에서 새 사용자를 생성하면 npm 레지스트리에 게시할 준비가 된 것입니다.

패키지는 공개 또는 비공개일 수 있습니다.

공개 패키지는 무료로 게시할 수 있으며 누구나 사용할 수 있습니다.

범위 패키지라고 하는 개인 패키지는 개인 모듈 사용자에게 비용을 지불한 경우에만 게시할 수 있으며 패키지 이름 앞에 추가되는 고유한 @username/ 으로 식별할 수 있습니다.

범위가 지정된 패키지는 --access=public 과 함께 publish 명령을 호출하여 공개적으로 게시할 수도 있습니다.

또한 패키지의 코드 기반을 확장하고 개선하는 데 더 많은 시간을 할애하고 새 버전을 게시해야 하는 경우 package.json 에서 패키지의 버전(semver 규칙 및 규칙에 따라)을 변경하기만 하면 됩니다. 파일을 입력하고 npm publish 를 입력합니다.

명령줄 인터페이스를 사용하고 npm version <update_type> 을 호출할 수도 있습니다. 여기서 update_type 은 semver 에서 설명한 대로 patch , minor 또는 major 입니다. 그러면 자동으로 package.json 파일의 버전 번호가 증가합니다.

npm 조직

다시 말하지만, 이에 대한 npm 문서는 훌륭하며 그들의 말을 반복하는 것은 무의미합니다.

npm 컨텍스트에서 조직에 대해 말할 수 있는 것은 조직이 매우 세분화되어 있으며 올바르게 관리될 때 한 이름으로 범위가 지정된 또는 공개 패키지에 대해 작업하는 대규모 팀과 개인이 매우 잘 관리되고 제한될 수 있다는 것입니다.

마스터하기는 복잡하지만 매우 보람이 있습니다.

npm의 힘

궁극적으로 npm이 제공하는 문서는 광범위하며 구체적인 내용은 참조해야 하지만 이 기사에서는 npm의 우수성을 전달하는 관련 기능의 기본 및 고급에 대한 유용한 개요를 제공합니다.

모든 것이 그렇듯이 강한 의견이 존재하고 많은 결함이 발견될 수 있습니다. 그러나 npm(또는 그 문제에 대해서는 node)을 시도한 적이 없다면 직접 뛰어들어 탐색하십시오. 당신이 생각하는 것보다 더 많이 즐길 가능성이 있습니다.

npm에 대한 더 흥미로운 기사를 보려면 npm 및 Browserify와 함께 Scala.js 사용을 읽어보세요.