프론트엔드(vue) 입문 과정: 학습 시작
요즘 프론트엔드 개발 학생들은 패키지 관리 도구인 npm 없이는 할 수 없습니다. npm의 뛰어난 패키지 버전 관리 메커니즘은 번영하는 NodeJS 커뮤니티 전체에 매우 유용합니다. 내부 메커니즘을 이해하는 것은 모듈 개발과 다양한 프런트 엔드 엔지니어링 구성에 대한 이해를 심화시켜 문제 해결 속도를 높이는 데 도움이 됩니다. (많은 학생들이 다양한 종속성 문제로 어려움을 겪고 있다고 생각합니다.)
이 기사에서는 package.json , 버전 관리, 종속성 설치 및 특정 예의 세 가지 관점에서 npm 의 패키지 관리 메커니즘을 자세히 분석합니다.
Node.js 에서 모듈은 라이브러리 또는 프레임워크이자 Node.js 프로젝트이기도 합니다. Node.js 프로젝트는 모듈식 아키텍처를 따릅니다. Node.js 프로젝트를 생성한다는 것은 모듈을 생성한다는 의미입니다. 즉, package.json 이라는 설명 파일이 있어야 합니다. 가장 일반적인 구성 파일입니다. 하지만 이 파일에 포함된 구성을 자세히 이해하셨나요? 합리적인 package.json 파일 구성은 프로젝트의 품질을 직접적으로 결정하므로 먼저 package.json 의 세부 구성을 분석하겠습니다.
package.json 에는 많은 속성이 있으며 그 중 name 및 version 두 가지 속성만 채워야 합니다. 이 두 속성은 npm 모듈의 고유 식별자를 구성합니다.
name 은 모듈 이름입니다. 이름을 지정할 때 일부 공식 사양과 권장 사항을 따라야 합니다.
패키지 이름은 모듈 url , 명령줄 또는 url 이 아닌 안전 문자의 매개 변수가 됩니다. 패키지 이름에는 둘 다 사용할 수 없습니다. validate-npm-package-name 사용하여 패키지 이름이 유효한지 확인할 수 있습니다.
의미론적 패키지 이름은 개발자가 필요한 패키지를 더 빨리 찾고 실수로 잘못된 패키지를 얻는 것을 방지하는 데 도움이 됩니다.
패키지 이름에 기호가 있는 경우 해당 기호를 제거한 후 기존 패키지 이름과 반복해서는 안 됩니다.
예를 들어, react-native 이미 존재하므로 react.native 및 reactnative 다시 생성할 수 없습니다.
예를 들어 사용자 이름은 conard 이고 범위는 @conard 이며 게시된 패키지는 @conard/react 일 수 있습니다.
name 패키지의 고유 식별자이며 다른 패키지 이름과 반복되어서는 안 됩니다. npm view packageName 실행하여 패키지가 점유되어 있는지 확인하고 이에 대한 몇 가지 기본 정보를 볼 수 있습니다.
패키지 이름이 한 번도 사용되지 않은 경우 404 오류가 발생합니다.
또한, https://www.npmjs.com/ 에서 자세한 패키지 정보를 확인할 수도 있습니다.
{
"description": "엔터프라이즈급 UI 디자인 언어 및 React 구성요소 구현",
"키워드": [
"개미",
"요소",
"구성 요소",
"설계",
"뼈대",
"프런트엔드",
"반응하다",
"반응 구성 요소",
"유이"
]
} description 다른 사람이 모듈을 쉽게 이해할 수 있도록 모듈 설명 정보를 추가하는 데 사용됩니다.
keywords 모듈에 키워드를 추가하는 데 사용됩니다.
물론 모듈 검색을 용이하게 하는 매우 중요한 역할도 합니다. npm search 사용하여 모듈을 검색하면 description 및 keywords 와 일치합니다. 좋은 description 과 keywords 작성하면 모듈이 점점 더 정확하게 노출되는 데 도움이 됩니다.
개발자를 설명하는 두 가지 필드가 있습니다: author 및 contributors author 패키지의 주요 작성자를 나타내며 한 author 한 사람에 해당합니다. contributors 정보는 contributors 한 명에 해당합니다. 값은 배열이거나 다음 구조일 수 있습니다
.
"이름": "코나드리",
"이메일": "[email protected]",
"url": "https://github.com/ConardLi"
} {
"홈페이지": "http://ant.design/",
"버그": {
"url": "https://github.com/ant-design/ant-design/issues"
},
"저장소": {
"유형": "git",
"url": "https://github.com/ant-design/ant-design"
},
} homepage 이 모듈의 홈페이지를 지정하는 데 사용됩니다.
repository 모듈의 코드 저장소를 지정하는 데 사용됩니다.
bugs 모듈에 대해 질문이 있는 사람들이 여기로 가서 질문을 제기할 수 있는 주소나 이메일을 지정합니다.
우리 프로젝트는 하나 이상의 외부 종속성 패키지에 의존할 수 있습니다. 종속성 패키지의 다양한 용도에 따라 dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies 속성으로 구성합니다.
종속성
구성 규칙을 살펴보겠습니다. 종속성 패키지 구성은 다음과 같습니다.
"antd": "ant-design/ant-design#4.0.0-alpha.8",
"축": "^1.2.0",
"test-js": "파일:../테스트",
"test2-js": "http://cdn.com/test2-js.tar.gz",
"core-js": "^1.1.5",
} 종속성 구성은 다음 구성 규칙을 따릅니다.
依赖包名称:VERSION VERSION 은 SemVer 사양을 따르는 버전 번호 구성입니다. npm install 시 지정된 버전 범위를 충족하는 패키지를 다운로드하기 위해 npm 서버로 이동합니다.依赖包名称:DWONLOAD_URL DWONLOAD_URL 은 다운로드 가능한 tarball 압축 패키지 주소입니다. 모듈이 설치되면 이 .tar 로컬로 다운로드되어 설치됩니다.依赖包名称:LOCAL_PATH LOCAL_PATH 는 file:../pacakges/pkgName 과 같은 로컬 종속성 패키지 경로입니다. npm 패키지를 로컬에서 테스트하는 데 적합하므로 이 방법은 온라인으로 적용하면 안 됩니다.依赖包名称:GITHUB_URL GITHUB_URL github 의 username/modulename 작성하는 방법입니다. 예: ant-design/ant-design 나중에 tag 와 commit id 지정할 수도 있습니다.依赖包名称:GIT_URL GIT_URL 은 다음 형식을 따르는 일반적인 복제 코드 베이스의 git url 입니다:<protocol>://[<user>[:<password>]@]<hostname>[:<port>] [: ][/]<경로>[#<commit-ish> | #semver:<semver>]
protocal 다음 형식일 수 있습니다:
git://github.com/user/project.git#commit-ishgit+ssh://user@hostname:project.git#commit-ishgit+ssh://user@hostname/project.git#commit-ishgit+http://user@hostname/project/blah.git#commit-ishgit+https://user@hostname/project/blah.git#commit-ish은
dependencies 가 의존하는 모듈을 지정합니다. 여기서는 개발 환경과 프로덕션 환경 종속성 모듈을 모두 구성할 수 있습니다.
종속성": {
"lodash": "^4.17.13",
"순간": "^2.24.0",
} 코드 사양 확인을 위한 eslint , 테스트용 jest 등 개발 환경에서만 사용할 수 있는 패키지가 있습니다. 사용자가 패키지를 사용하면 이러한 종속성을 설치하지 않고도 정상적으로 실행할 수 있습니다.
devDependency
devDependencies 추가할 수 있습니다. 이러한 종속성은 npm install 로컬로 수행할 때 계속 설치 및 관리되지만 프로덕션 환경에는 설치되지 않습니다.
"농담": "^24.3.1",
"에슬린트": "^6.1.0",
} peerDependencies 는 개발 중인 모듈이 의존하는 버전과 사용자가 설치한 종속 패키지 버전의 호환성을 지정하는 데 사용됩니다.
위의 설명은 다소 추상적일 수 있습니다. ant-design 예로 들어보겠습니다. ant-design 의 package.json 다음과 같은 구성을 갖습니다
.
"반응": ">=16.0.0",
"반응-돔": ">=16.0.0"
} 시스템을 개발하고 ant-design 사용할 때 반드시 React 에 의존해야 합니다. 동시에 ant-design 도 React 에 의존해야 합니다. 안정적인 작동을 유지하기 위해 필요한 React 버전은 16.0.0 이고, 개발할 때 의존하는 React 버전은 15.x 입니다.
이때 ant-design React 사용해야 하고 그것을 가져와야 합니다:
import * as React from 'react'; import * as ReactDOM from 'react-dom';
이때 얻게 되는 것은 호스트 환경이며, 이는 귀하 환경의 React 버전이므로 몇 가지 문제가 발생할 수 있습니다. npm2 에서, 위의 peerDependencies 지정한다는 것은 호스트 환경이 react@>=16.0.0和react-dom@>=16.0.0 버전을 설치하도록 강제한다는 것을 의미합니다.
앞으로는 npm3 더 이상 peerDependencies 로 지정된 종속성 패키지를 강제로 설치할 필요가 없습니다. 반대로 npm3 설치가 완료된 후 설치가 올바른지 확인하여 잘못된 경우 사용자에게 경고를 표시합니다. .
"종속성": {
"반응": "15.6.0",
"개미": "^3.22.0"
} 예를 들어 프로젝트에서 최신 버전의 antd 사용하고 15.6.0 버전의 react 사용하면 종속성을 설치할 때 다음 경고가 표시됩니다.
일부 시나리오에서는 종속 패키지가 강력한 종속성이 아닐 수 있습니다. 이 종속 패키지를 얻을 수 없는 경우에는 npm install 실패 없이 계속 실행되도록 할 수 있습니다. optionalDependencies 의 구성 optionalDependencies dependencies 재정의하므로 한 위치에서만 구성하면 됩니다.
물론, optionalDependencies 에 설치된 의존성을 참조할 때는 예외 처리를 해야 하며, 그렇지 않으면 모듈을 얻을 수 없을 때 오류가 보고됩니다.
는 위와 다릅니다. bundledDependencies 의 값은 배열입니다. 일부 모듈은 이 패키지가 출시될 때 함께 패키지됩니다.
"bundledDependency": ["package1" , "package2"]
{
"라이센스": "MIT"
} license 필드는 소프트웨어의 오픈 소스 계약을 지정하는 데 사용됩니다. 오픈 소스 계약은 귀하의 코드를 획득한 후 다른 사람이 갖는 권리, 귀하의 코드에서 수행할 수 있는 작업 및 금지되는 작업을 자세히 설명합니다. 동일한 계약에도 다양한 변형이 있습니다. 너무 느슨한 계약은 저작자에게 저작물에 대한 많은 권리를 잃게 만들고, 너무 엄격한 계약은 사용자가 저작물을 사용하고 배포하는 데 편리하지 않습니다. , 오픈 소스 작성자는 어떤 권리를 유지하고 어떤 제한을 완화할지 고려해야 합니다.
소프트웨어 계약은 오픈 소스와 상업용의 두 가지 범주로 나눌 수 있습니다. 법적 진술과 라이센스 계약이라고도 하는 상업적 계약의 경우 각 소프트웨어에는 소프트웨어 작성자 또는 전문 변호사가 작성한 고유한 텍스트 세트가 있습니다. 긴 라이센스 계약을 작성하는 데 시간과 노력을 들일 필요가 없습니다. 널리 배포되는 오픈 소스 라이센스를 선택하는 것이 좋습니다.
다음은 몇 가지 주류 오픈 소스 프로토콜입니다.
MIT : 사용자가 프로젝트 복사본에 저작권 표시와 라이센스 표시를 포함하는 한, 사용자는 어떠한 책임도 지지 않고 코드로 원하는 모든 작업을 수행할 수 있습니다.Apache : MIT 와 유사하지만 기여자가 사용자에게 제공하는 특허 라이센스와 관련된 용어도 포함합니다.GPL : 프로젝트 코드를 수정하는 사용자는 소스 코드나 바이너리 코드를 재배포할 때 관련 수정 사항을 게시해야 합니다.오픈 소스 계약에 대한 더 자세한 요구 사항이 있는 경우 choosealicense.com/으로 이동하여 오픈 소스 계약에 대한 자세한 설명을 볼 수 있습니다.
{
"메인": "lib/index.js",
} main 속성은 프로그램의 기본 항목 파일을 지정할 수 있습니다. 예를 들어 위의 antd 에 의해 지정된 모듈 antd lib/index.js 다음과 같습니다. 실제로 import { notification } from 'antd'; 소개된 것은 lib/index.js 입니다.
모듈이 명령줄 도구인 경우 명령줄 도구에 대한 항목을 지정해야 합니다. 즉, 명령 이름과 로컬 지정 가능 파일 간의 대응 관계를 지정해야 합니다. 전역적으로 설치된 경우 npm은 심볼릭 링크를 사용하여 실행 파일을 /usr/local/bin 에 연결합니다. 로컬로 설치된 경우 ./node_modules/.bin/ 에 연결됩니다.
{
"빈": {
"코나드": "./bin/index.js"
}
} 예를 들어 위 구성은 다음과 같습니다. 패키지가 전역적으로 설치된 경우 npm "./bin/index.js" 를 가리키는 /usr/local/bin 아래에 conard 라는 소프트 링크를 생성합니다. . 이때, command line에서 conard 실행하면 연결된 js 파일이 호출됩니다.
여기서는 너무 자세히 설명하지 않겠습니다. 더 많은 내용은 다음 명령줄 도구 기사에서 자세히 설명하겠습니다.
{
"파일": [
"거리",
"lib",
"에스"
]
} files 속성은 npm publish 후 npm 서버에 푸시하는 파일 목록을 설명하는 데 사용됩니다. 폴더를 지정하면 폴더의 모든 내용이 포함됩니다. 다운로드한 패키지의 디렉터리 구조는 다음과 같습니다.
또한 많은 수의 정크 파일이
npm으로 푸시되는 것을 방지하기 위해 일부 파일을 제외하도록.npmignore파일을 구성할 수도 있습니다. 규칙은 사용하는.gitignore와 동일합니다..gitignore파일은.npmignore파일 역할을 할 수도 있습니다.
man 명령은 Linux 에서의 help 명령입니다. man 명령을 통해 Linux 에서 명령 도움말, 구성 파일 도움말, 프로그래밍 도움말 및 기타 정보를 볼 수 있습니다.
node.js 모듈이 전역 명령줄 도구인 경우 package.json 의 man 속성을 통해 man 명령으로 검색한 문서 주소를 지정할 수 있습니다.
man 파일은 숫자로 끝나거나 압축된 경우 .gz 로 끝나야 합니다. 숫자는 파일이 설치될 man 의 어느 부분을 나타냅니다. man 파일 이름이 모듈 이름으로 시작하지 않으면 설치 중에 모듈 이름이 앞에 붙습니다.
예를 들어 다음 구성은 다음
과 같습니다.
"남성" : [
"/Users/isaacs/dev/npm/cli/man/man1/npm-access.1",
"/Users/isaacs/dev/npm/cli/man/man1/npm-audit.1"
]
} 명령줄에 man npm-audit 입력합니다.
CommonJS node.js 은 CommonJS 모듈 사양을 기반으로 구현되며 패키지 설명 파일 package.json 외에도 모듈 디렉터리에는 다음 디렉터리도 포함되어야 합니다.
bin : 여기서 실행 가능한 바이너리 파일이 저장됩니다. 디렉토리lib : js 코드가 저장되는 디렉토리doc : 문서가 저장되는 디렉토리test : 단위 테스트 케이스 코드가 저장되는 디렉토리모듈 디렉토리에서는 위의 구조를 엄격하게 따르지 않거나 이름을 지정할 수 없습니다. . package.json 속성에서 directories 지정하여 디렉터리 구조가 위의 표준 구조와 일치하는 방식을 지정할 수 있습니다. 이 외에도 directories 속성에는 당분간 다른 응용 프로그램이 없습니다.
{
"디렉터리": {
"lib": "src/lib/",
"빈": "src/bin/",
"남자": "src/남자/",
"doc": "src/doc/",
"예제": "src/예제/"
}
} 그러나 공식 문서에는 이 속성이 현재는 중요한 역할을 하지 않지만 앞으로 몇 가지 트릭이 개발될 수 있다고 명시되어 있습니다. 예를 들어 doc에 저장된 마크다운 파일과 example에 저장된 예제 파일이 친숙한 방식으로 표시될 수 있습니다.
{
"스크립트": {
"테스트": "jest --config .jest.js --no-cache",
"dist": "antd-tools는 dist를 실행합니다",
"compile": "antd-tools 실행 컴파일",
"build": "npm 실행 컴파일 && npm 실행 dist"
}
} scripts 일부 스크립트 명령의 약어를 구성하는 데 사용됩니다. 각 스크립트는 서로 조합하여 사용할 수 있습니다. 이러한 스크립트는 구성 후 npm run command 사용하여 호출할 수 있습니다. npm 키워드인 경우 직접 호출할 수 있습니다. 예를 들어 위 구성은 npm run test , npm run dist , npm run compile , npm run build 명령을 지정합니다.
config 필드는 스크립트에 사용되는 환경 변수를 구성하는 데 사용됩니다. 예를 들어 스크립트에서 process.env.npm_package_config_port 사용하여 다음 구성을 얻을 수 있습니다.
{
"구성": { "포트": "8080" }
} node.js 모듈이 주로 전역 명령줄 도구를 설치하는 데 사용되는 경우 이 값은 true 로 설정되며 사용자가 모듈을 로컬로 설치할 때 경고가 표시됩니다. 이 구성은 사용자가 설치하는 것을 방지하지는 않지만 일부 문제를 일으킬 수 있는 잘못된 사용을 방지하도록 사용자에게 메시지를 표시합니다.
private 속성이 true 로 설정되면 npm은 이를 게시하는 것을 거부합니다. 이는 비공개 모듈이 실수로 게시되는 것을 방지하기 위한 것입니다.
"publishConfig": {
"레지스트리": "https://registry.npmjs.org/"
}, 모듈을 게시할 때 더 자세한 구성을 수행합니다. 예를 들어 특정 tag 만 게시하도록 구성하고 게시할 비공개 npm 소스를 구성할 수 있습니다. 보다 자세한 구성은 npm-config os를 참고하세요
darwin 시스템에서만 실행 가능한 모듈을 개발하는 경우, 불필요한 오류를 방지하기 위해 windows 사용자가 해당 모듈을 설치하지 않도록 해야 합니다.
os 속성을 사용하면 위의 요구 사항을 충족하는 데 도움이 될 수 있습니다. 모듈을 특정 시스템에만 설치할 수 있도록 지정하거나 설치할 수 없는 시스템의 블랙리스트를 지정할 수 있습니다.
"os" : [ "darwin", "linux" ] "os" : [ "!win32" ]
예를 들어, 시스템 블랙리스트에 테스트 모듈을 할당합니다: "os" : [ "!darwin" ] 이 시스템에 설치하면 다음 오류가 나타납니다.
노드 환경에서는 process.platform을 사용하여 운영 체제를 확인할 수 있습니다.
위의 os 와 유사합니다. cpu 속성을 사용하여 사용자의 설치 환경을 보다 정확하게 제한할 수 있습니다.
"cpu" : [ "x64", "ia32" ] "cpu" : [ "!arm", "!mips" ]
노드 환경에서는 process.arch를 사용하여 CPU 아키텍처를 결정할 수 있습니다.
Nodejs 의 성공은 npm 의 뛰어난 종속성 관리 시스템과 불가분의 관계에 있습니다. 전체 종속성 시스템을 소개하기 전에 npm 종속 패키지의 버전을 관리하는 방법을 이해해야 합니다. 이 장에서는 npm包의 버전 릴리스 사양, 다양한 종속 패키지의 버전을 관리하는 방법 및 패키지 버전과 관련된 몇 가지 모범 사례를 소개합니다.
npm view package version 실행하면 package 의 최신 버전을 볼 수 있습니다.
npm view conard versions 실행하면 npm 서버에 게시된 모든 package 버전을 볼 수 있습니다.
npm ls 실행하여 현재 웨어하우스 종속성 트리에 있는 모든 패키지의 버전 정보를 확인하세요.
npm包의 모듈 버전은 SemVer 사양( Github 에서 초안한 안내, 통합 버전 번호 표시 규칙)을 따라야 합니다. 실제로는 Semantic Version 의 약어입니다.
SemVer 사양 공식 웹사이트: https://semver.org/Standard
SemVer 사양의 표준 버전 번호는 XYZ 형식을 채택합니다. 여기서 X, Y 및 Z는 음수가 아닌 정수이고 숫자 앞의 제로 패딩은 다음과 같습니다. 금지. X는 주 버전 번호, Y는 부 버전 번호, Z는 개정 번호입니다. 각 요소는 수치적으로 증가해야 합니다.
major ): 호환되지 않는 API 수정을 하는 경우minor ): 이전 버전과 호환되는 기능을 만드는 경우 새patch ): 이전 버전과의 호환성 문제를 만드는 경우 수정합니다.예: 1.9.1 -> 1.10.0 -> 1.11.0
버전에 큰 변경 사항이 있고, 안정적이지 않으며, 예상되는 호환성 요구 사항을 충족하지 못하는 경우 고급 버전을 먼저 릴리스할 수 있습니다.
선행 버전 번호는 "주 버전 번호, 부 버전 번호, 개정 번호" 끝에 추가할 수 있습니다. 먼저 연결 번호를 추가한 다음 마침표로 구분된 일련의 식별자와 버전 컴파일 정보를 추가합니다.
alpha ):beta ):rc Release candiateReact 살펴보겠습니다
버전은 SemVer 사양에 따라 엄격하게 릴리스되었음을 알 수 있습니다.
主版本号.次版本号.修订号16.8.0 -> 16.8.1 -> 16.8.216.8.0 -> 16.8.1 -> 16.8.2alpha , beta , rc 및 기타 고급 버전이. npm 패키지의 특정 기능을 수정한 후 일반적으로 우리의 일반적인 접근 방식은 package.json 지정된 버전으로 직접 수정하는 것입니다. 작업이 올바르지 않으면 버전 번호에 혼동이 생기기 쉽습니다. Semver 사양을 준수하는 명령을 사용하여 이 작업을 완료할 수 있습니다.
npm version patch : 개정 번호 업그레이드npm version minor : 마이너 버전 번호npm version majornpm version major : 메이저 버전 번호일부 버전 번호의 작동에 반드시 필요합니다. 이러한 버전 번호가 SemVer 사양을 준수하는 경우 운영 버전에 npm 패키지 semver 사용하여 도움을 받을 수 있습니다. 버전 크기 비교, 버전 정보 추출 및 기타 작업을 수행합니다.
Npm은 또한 이 도구를 사용하여 버전 관리 작업을 처리합니다.
npm install semver
semver.gt('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true는 semver.valid('1.2.3') // '1.2.3'
semver.valid('abc') // null은 semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // '42.6.7' semver.clean(' =v1.2.3 ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
semver.minVersion('>=1.0.0') // '1.0.0' 위의 내용은 semver의 가장 일반적인 용도입니다. 자세한 내용은 semver 설명서(https://github.com/npm/node)를 참조하세요. -semver
우리는 package.json 에서 다양한 종속성을 작성하는 다양한 방법을 종종 볼 수 있습니다
.
"신호": "1.4.0",
"figlet": "*",
"반응": "16.x",
"테이블": "~5.4.6",
"yargs": "^14.0.0"
} 처음 세 개는 이해하기 쉽습니다.
"signale": "1.4.0" : 고정 버전 번호"figlet": "*" : 모든 버전( >=0.0.0 )"react": "16.x" : 일치 메인 버전( >=16.0.0 <17.0.0 )"react": "16.3.x" : 메이저 버전과 마이너 버전 일치( >=16.3.0 <16.4.0 )마지막 두 버전을 살펴보겠습니다. 버전 번호 ~ 및 ^ 기호는 다음과 같이 인용됩니다.
~ : 종속성을 설치할 때 새 버전을 얻으면 xyz 에 최신 버전의 z 설치합니다. 즉, 메이저 버전 번호와 마이너 버전 번호를 변경하지 않고 최신 개정 번호를 유지합니다.^ : 종속성을 설치할 때 새 버전을 얻으면 설치된 xyz 의 y 와 z 모두 최신 버전입니다. 즉, 메이저 버전 번호는 그대로 유지하면서 마이너 버전 번호와 개정 번호는 최신 버전으로 유지합니다.package.json 파일의 가장 일반적인 종속성은 "yargs": "^14.0.0" 이어야 합니다. 왜냐하면 npm install package 사용하여 패키지를 설치할 때 npm 기본적으로 최신 버전을 설치한 다음 Add에 설치하기 때문입니다. 버전 번호 앞에 ^ 기호가 있습니다.
주 버전 번호가 0 이면 불안정한 버전으로 간주됩니다. 상황은 위와 다릅니다.
0 입니다. ^0.0.z 및 ~0.0.z 는 모두 0입니다. 고정 버전으로 간주되므로 종속성을 설치할 때 변경 사항이 발생하지 않습니다.0 입니다. ^0.yz ~0.yz 와 동일하게 동작하며 개정 번호만 최신 버전으로 유지됩니다.버전 번호 1.0.0은 공개 API를 정의하는 데 사용됩니다. 귀하의 소프트웨어가 공식 환경에 출시되거나 안정적인 API가 있으면 버전 1.0.0을 출시할 수 있습니다. 따라서 npm 패키지의 공식 버전을 외부에 출시하기로 결정한 경우 해당 버전을 1.0.0으로 표시하세요.
실제 개발에서는 다양한 종속성의 불일치로 인해 이상한 문제가 자주 발생하거나 일부 시나리오에서는 종속성을 업데이트하지 않으려는 경우 개발 중에 package-lock.json 사용하는 것이 좋습니다.
종속성 버전을 잠그면 수동으로 업데이트를 수행하지 않는 한 종속성을 설치할 때마다 수정된 버전이 설치됩니다. 전체 팀이 일관된 버전 번호의 종속성을 사용하는지 확인하세요.
고정 버전을 설치할 때마다 종속성 버전 범위를 계산할 필요가 없으므로 대부분의 시나리오에서 종속성 설치 시간이 크게 단축될 수 있습니다.
package-lock.json을 사용할 때 npm 버전이 5.6 이상인지 확인하세요. 5.0과 5.6 사이에서 package-lock.json의 처리 로직이 여러 번 업데이트되고 버전 5.6의 후처리 로직이 점차 안정화되었기 때문입니다.
이후 장에서 package-lock.json 의 세부 구조를 분석할 것입니다.
목적은
이러한 종속성을 절대 업데이트하지 않고 팀에서 사용되는 종속성이 일관되고 안정적인지 확인하는 것입니다.실제 개발 시나리오에서는 매번 새 버전을 설치할 필요는 없지만 종속성 패키지 업그레이드로 인한 문제 수정, 성능 개선 및 새로운 기능 업데이트를 즐길 수 있도록 정기적으로 종속성 버전을 업그레이드해야 합니다.
npm outdated 사용하면 최신 버전으로 업그레이드되지 않은 종속성을 나열하는 데 도움이 될 수 있습니다.
하고 npm update 실행하세요. 모든 빨간색 종속성을 업그레이드하세요.
1.0.0 으로 표시하세요.主版本号.次版本号.修订号릴리스alpha、beta、rc 및 다른 고급 버전을 먼저 선택하세요.npm 패키지입니다. 이때 버전 접두어가 잠겨 ~ 변경하는 것이 좋습니다. 메인 프로젝트의 종속성은 하위 종속성이 업데이트될 때마다 업그레이드해야 하는데, 이는 매우 번거로운 작업입니다. 하위 종속성이 완전히 신뢰된 경우 직접 엽니다 ^ 매번 최신 버전으로 업그레이드하세요.docker 라인에서 실행되며 하위 종속성은 여전히 로컬에서 개발 및 업그레이드되고 있습니다. docker 버전이 출시되기 전에 로컬 하위 종속성이 해제된 후 온라인에서 문제가 발생하지 않도록 모든 종속성 버전을 잠가야 합니다. 출시된.npm 버전이 5.6 이상인지 확인하고, package-lock.json 파일이 기본적으로 활성화되어 있는지 확인하세요.npm inatall 실행된 후 package-lock.json 원격 창고에 제출됩니다. node_modules 원격 저장소에 직접 제출하지 마십시오.npm update 실행하여 종속성을 업그레이드하고, 다른 구성원이 동시에 종속성을 업데이트할 수 있도록 lock 파일을 제출하세요. lock 파일을 수동으로 변경하지 마세요.package.json 파일의 종속성 버전을 수정하고 npm install 실행locknpm install package@version 직접 실행( package.json 변경해도 종속성이 다운그레이드되지 않음)
npm install 아마도 위의 과정을 거치게 될 것입니다. 이 장에서는 각 프로세스의 구현 세부 사항, 개발 및 이유에 대해 설명합니다.
우리 모두는 npm install 실행한 후 종속 패키지가 node_modules 에 설치된다는 것을 알고 있습니다. npm 종속 패키지를 node_modules 에 설치하는 구체적인 메커니즘을 자세히 살펴보겠습니다.
npm 의 초기 버전에서 npm 종속성 처리 방식은 간단하고 조잡했습니다. 이는 package.json 구조와 하위 종속성 패키지의 package.json 구조를 엄격하게 따라 재귀적인 방식으로 해당 node_modules 에 종속성을 설치했습니다. 더 이상 다른 모듈에 의존하지 않는 하위 종속 패키지가 나올 때까지.
예를 들어, my-app 모듈은 이제 buffer 와 ignore 두 모듈에 의존합니다
.
"이름": "내 앱",
"종속성": {
"버퍼": "^5.4.3",
"무시": "^5.1.4",
}
} ignore 다른 모듈에 의존하지 않는 순수 JS 모듈이며, buffer base64-js 및 ieee754 두 모듈에 의존합니다.
{
"이름": "버퍼",
"종속성": {
"base64-js": "^1.0.2",
"ieee754": "^1.1.4"
}
} 그런 다음 npm install 실행한 후 얻은 node_modules 의 모듈 디렉터리 구조는 다음과 같습니다.
이 접근 방식의 장점은 명백합니다. node_modules 의 구조는 package.json 의 구조와 일대일로 대응하고, 계층 구조가 명확하며, 각 설치의 디렉터리 구조가 동일하다는 것이 보장됩니다.
그러나 많은 모듈에 의존한다면 node_modules 가 매우 크고 중첩 수준이 매우 깊어질 것이라고 상상해 보십시오.
Windows 시스템에서 최대 파일 경로 길이는 260자이며 중첩 수준이 너무 깊으면 예측할 수 없는 문제가 발생할 수 있습니다.위의 문제를 해결하기 위해 NPM 버전 3.x 에서 대규모 업데이트를 진행했습니다. 초기 중첩 구조를 플랫 구조로 변경합니다.
node_modules 루트 디렉터리에 설치됩니다.위의 종속성 구조를 유지하면서 npm install 실행하면 다음 디렉터리 구조를 얻게 됩니다.
현재 모듈에서 [email protected] 버전에 의존하면 :
{
"이름": "My-App",
"종속성": {
"버퍼": "^5.4.3",
"무시 :"^5.1.4 ",
"Base64-JS": "1.0.1",
}
} node_modules 를 일치시킵니다.이 시점에서 npm install 실행 한 후 다음 디렉토리 구조를 얻게됩니다.
이에 따라 프로젝트 코드의 모듈을 참조하면 모듈 검색 프로세스
node_modulesnode_modules패키지 buffer2@^5.4.3 [email protected] 따라
node_modules 경로가 검색되며
따라서 npm 3.x 버전은 이전 버전의 모듈 중복성 문제를 완전히 해결하지 못하고 새로운 문제를 일으킬 수도 있습니다.
앱이 [email protected] 버전에 의존하지 않지만 다른 base64-js 버전에 의존하는 buffer 및 buffer2 에도 의존한다고 상상해보십시오. npm install 실행할 때 package.json 의 종속성은 순서대로 구문 분석되므로 buffer 와 buffer2 의 순서가 package.json 에 배치됩니다 .json은 node_modules 의 종속성 구조를 결정합니다.
buffer2 에 의존합니다.
먼저 buffer 에 의존합니다.
또한 개발자가 안전 전제에 따라 최신 종속성 패키지를 사용할 수 있도록하기 위해서는 일반적으로 큰 버전 만 package.json 만 잠그게합니다. 즉, 일부 종속성 패키지의 마이너 버전이 업데이트되면 종속성 구조가 업데이트 될 수 있습니다. 의존성 구조에서 불확실성이 변경되면 프로그램에 예측할 수없는 문제가 발생할 수 있습니다.
npm install 의 불확실성 문제를 해결하기 위해 package-lock.json 파일이 npm 5.x 버전에 추가되었으며 설치 방법은 npm 3.x 의 플랫 메소드를 따릅니다.
package-lock.json 의 기능은 디렉토리에 package-lock.json 파일이있는 한 npm install 의 각 실행 후 생성 된 node_modules 디렉토리 구조가있는 한 종속성 구조를 잠그는 것입니다. .
예를 들어, 우리는 다음의 종속성 구조를 가지고 있습니다.
{
"이름": "My-App",
"종속성": {
"버퍼": "^5.4.3",
"무시 :"^5.1.4 ",
"Base64-JS": "1.0.1",
}
} npm install 실행 한 후 생성 된 package-lock.json 다음과 같습니다
.
"이름": "My-App",
"버전": "1.0.0",
"종속성": {
"Base64-JS": {
"버전": "1.0.1",
"Resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
"무결성": "SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG ="
},
"버퍼": {
"버전": "5.4.3",
"Resolved": "https://registry.npmjs.org/buffer/-/buffer-5.4.3.tgz",
"무결성": "SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJQQGS4O/SNOEZG1f1f1KYAP9NU2JCUDPWZRSJTHMMMZG0H7BZKN4RNQPIMHUXWX2A ==",
"필수": {
"Base64-JS": "^1.0.2",
"IEEE754": "^1.1.4"
},
"종속성": {
"Base64-JS": {
"버전": "1.3.1",
"Resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.tgz",
"무결성": "SHA512-MLQ4I2QO1YTVGWFWMCNGKO // jXAQUEZVWEKTJGQFM4JIK0KU+YTMFPLL8J+N5MSPOFJHWOAG+9YHB7BWAHM36G =="
}
}
},
"IEEE754": {
"버전": "1.1.13",
"Resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.1.13.tgz",
"무결성": "SHA512-4VF7I2LYV/HAWERSO3XMLMKP5EZ83I+/CDLUXI/igts/O1Sejbnhttnxzmrzfvouqj7lzjqhketvpgsfdlwztg =="
},
"무시하다": {
"버전": "5.1.4",
"Resolved": "https://registry.npmjs.org/ignore/-/ignore-5.1.4.tgz",
"무결성": "SHA512-MZBUSAHKTW1U7JPKKKJY7LCARD1FU5W2RLDXLM4KDKAYUCWZIMJKPLUF9CM1ALEWYJGUPDQEWLAM18Y6AU69A8A ==" "
}
}
} 위의 구조를 자세히 살펴 보겠습니다.
두 개의 바깥 쪽 속성 name 과 version package.json 의 name 및 version 과 동일하며 현재 패키지 이름과 버전을 설명하는 데 사용됩니다.
dependencies node_modules 의 패키지 구조에 해당하는 객체입니다. 객체의 key 패키지 이름이며 값은 패키지의 일부 설명입니다.
version : 패키지 버전 - 현재 node_modules 에 설치된이 패키지의 버전resolved : 패키지 특정 설치 소스integrity : 설치된 소프트웨어 패키지가 수정되었는지 여부를 확인하기 위해 Subresource Integrity 을 기반으로 한 패키지 hash 값requires 은 하위의 dependencies 과 동일합니다. 종속성 package.json .dependencies : 구조는 외부 dependencies 구조와 동일하며 하위 의존성 node_modules 에 설치된 종속성 패키지를 저장합니다.여기서 모든 하위 의존성에 dependencies 속성이있는 것은 아닙니다.이 속성은 하위 의존성의 종속성이 루트 디렉토리의 node_modules 에 현재 설치된 종속성과 충돌 한 후에 만 나타납니다.
예를 들어, 위의 종속성을 검토하십시오.
[email protected] 버전에서 우리는 base64-js@^1.0.2 와 my-app buffer 에 의존하는 버전에서 의존하여 [email protected] 의 node_modules 에 설치해야합니다. package-lock.json 에서 buffer 의 dependencies 속성에 해당하는 buffer 패키지가 변경되었습니다. 이것은 또한 npm 의 종속성에 대한 평평한 접근 방식에 해당합니다.
따라서 위의 분석에 따르면 package-lock.json package-lock.json 과 node_modules 디렉토리 구조는 일대일 서신에 있습니다. 각 설치에 의해 생성됩니다.
또한 프로젝트에서 package-lock.json 을 사용하면 종속성 설치 시간의 속도를 크게 높일 수 있습니다.
npm i --timing=true --loglevel=verbose lock lock 사용하여 npm install 의 전체 프로세스를 확인하겠습니다. 비교하기 전에 npm 캐시를 청소하십시오.
lock 파일을 사용하지 않고 :
lock 파일 사용 :
각 패키지의 특정 버전 및 다운로드 링크는 package-lock.json 에 캐시되었음을 알 수 있습니다. 많은 수의 네트워크 요청.
시스템 응용 프로그램을 개발할 때는 모든 팀 개발자가 설치 한 종속성 버전과 npm install 실행할 때 CI 버전 저장소에 package-lock.json 파일을 제출하는 것이 좋습니다.
npm 패키지를 semver 때는 npm 패키지가 다른 리포지토리에 의존해야합니다 범위 내에서 불필요한 중복성을 유발합니다. 따라서 package-lock.json 파일을 게시해서는 안됩니다 ( npm 기본적으로 package-lock.json 파일을 게시하지 않습니다).
npm install 또는 npm update 명령을 실행 한 후 종속성을 다운로드하려면 node_modules 디렉토리에 종속성 패키지를 설치하는 것 외에도 로컬 캐시 디렉토리에 사본도 캐시됩니다.
npm config get cache 명령 : Linux 또는 Mac 에서 기본값은 사용자의 홈 디렉토리의 .npm/_cacache 디렉토리입니다.
이 디렉토리에는 content-v2 와 index-v5 두 디렉토리가 있습니다. content-v2 디렉토리는 tar 패키지의 캐시를 저장하는 데 사용되며 index-v5 디렉토리는 tar 패키지의 hash 저장하는 데 사용됩니다.
NPM이 설치를 실행할 때 package-lock.json 에 저장된 integrity、version、name 기반으로 index-v5 디렉토리의 캐시 레코드에 해당하는 고유 key 생성하여 tar 패키지의 hash 찾을 수 있습니다. 그리고 hash tar 으로하는 것은 직접 사용됩니다.
캐시 디렉토리에서 검색 및 테스트 할 패키지를 찾을 수 있으며 index-v5 :
grep "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1에서 패키지 경로를 검색 할 수 있습니다. TGZ "-R Index -V5
그런 다음 우리는 JSON을 포맷합니다
.
"키": "Pacote : 버전-관리 : https : //registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz : sha1-asbrszt7xze47tutdw3i/np+pag =",
"무결성": "SHA512-C2EKHXWXVLSBRUCJTRS3FHV7MF/Y9KLKDXPTE8YEVCOH5H8AE69Y+/LP+AHPW91CRNZGO78ELOK2E6APJFIQ ==",
"시간": 1575554308857,
"크기": 1,
"메타 데이터": {
"ID": "[email protected]",
"매니페스트": {
"이름": "Base64-JS",
"버전": "1.0.1",
"엔진": {
"노드": "> = 0.4"
},
"종속성": {},
"옵션 의존성": {},
"devDependency": {
"표준": "^5.2.2",
"테이프": "4.x"
},
"번들 의존성": 거짓,
"PeerDependencies": {},
"감가 상각": 거짓,
"_resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
"_integrity": "SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG =",
"_shasum": "6926D1B194FBC737B8EED513756DE2FCDA7EA408",
"_shrinkwrap": null,
"빈": NULL,
"_id": "[email protected]"
},
"유형": "최종 관리"
}
} 위의 _shasum 속성 6926d1b194fbc737b8eed513756de2fcda7ea408 은 tar 패키지의 hash 이며, hash 의 첫 번째 숫자 6926 디렉토리에 입력했을 때 첫 두 레벨의 캐시 디렉토리입니다.
위의 캐싱 전략은 NPM V5 버전에서 시작하여 각 캐시 된 모듈은 모듈 이름 형태의 ~/.npm 폴더에 직접 저장되며 스토리지 구조는 {cache}/{name}/{버전입니다. }.
npm 캐시 데이터를 관리하기위한 몇 가지 명령을 제공합니다.
npm cache add : 공식 설명은이 명령이 주로 npm 에서 내부적으로 사용되지만 지정된 패키지에 캐시를 수동으로 추가하는 데 사용될 수도 있습니다.npm cache clean : 캐시 디렉토리의 모든 데이터를 삭제하려면 캐시 데이터의 무결성을 확인하려면 --force 매개 변수를 추가해야합니다.npm cache verify : 캐시 데이터의 유효성과 무결성을 확인하고 정크 데이터를 정리하십시오.캐시 된 데이터를 기반으로 NPM은 다음과 같이 오프라인 설치 모드를 제공합니다.-
--prefer-offline : 캐시 된 데이터가 일치하지 않으면 원격 창고에서 다운로드하십시오.--prefer-online : 네트워크 데이터 요청이 실패한 경우이 모드는 최신 모듈을 얻을 수 있습니다.--offline : 캐시 된 데이터가 존재하지 않으면 캐시 된 데이터를 직접 사용하지 마십시오.파일 무결성을 여러 번 언급 했으므로 파일 무결성 확인이란 무엇입니까?
tarball 패키지를 다운로드하기 전에 일반적으로 npm info 명령을 실행하면 npm shasum 의해 계산 된 hash 값 hash 얻을 수 있습니다.
사용자는 종속성 패키지를 로컬로 다운로드 한 후 다운로드 프로세스 중에 오류가 발생하지 hash hash 동일합니다. 다운로드 된 의존성이 다른 경우, 다른 경우.
전체 프로세스가 완료되었으므로 위의 프로세스를 요약하겠습니다.
.npmrc 파일을 확인하십시오. 우선 순위는 다음과 같습니다. Project-level .npmrc 파일> 사용자 수준 .npmrc 파일> 글로벌 레벨 .npmrc 파일> NPM 내장 내장. .npmrc 파일
프로젝트에 lock 파일이 있는지 확인하십시오.
lock 파일 없음 :
npm 원격 창고에서 패키지 정보를 얻고package.json 기반으로 종속성 node_modules 루트 디렉토리에서.node_modules 에서.npm 에서 원격 창고 다운로드 패키지는npm 캐시 디렉토리로 복사node_modules 로 추출합니다.lock
package-lock.json package.jsonnode_modulesnode_moduleslock 을 생성합니다package-lock.json .
위의 프로세스는 npm install package --timing=true --loglevel=verbose npm install 의 일반적인 프로세스를 간략하게 설명합니다. 특정 패키지의 설치 프로세스 및 세부 사항.
yarn 2016 에 출시되었습니다. 그 당시 npm 여전히 V3 언급 한 것처럼 package-lock.json 파일이 없었습니다. 개발자의. 이 시점에서 yarn 사는 다음과 같습니다.
위는 공식 웹 사이트에서 언급 된 yarn 의 장점이며, 그 당시에는 여전히 매우 매력적이었습니다. 물론 npm 나중에 자체 문제를 실현하고 후속 최적화 ( lock 파일, 캐시, 기본값)에서 yarn 의 그림자 yarn 볼 수 있습니다 디자인은 여전히 매우 좋습니다.
의존성
yarn npm v3 yarn.lock yarn.lock .
자율 파일입니다.이 파일을 직접 편집하지 마십시오. # 원사 잠금 파일 v1 [email protected] : 버전 "1.0.1" "https://registry.yarnpkg.com/base64-js/-/base64-js-1.0.1.tgz#6926D1B194FBC737B8EED513756DE2FCDA7EA408". 무결성 SHA1-ASBRSZT7XZE47TUTDW3I/NP+PAG = base64-js@^1.0.2 : 버전 "1.3.1" "https://registry.yarnpkg.com/base64-js/-/base64-js-1.3.1.tgz#58ece8cb75ddd07e71ed08c736abc5fac4dbf8df1" 무결성 SHA512-MLQ4I2QO1YTVGWFWMCNGKO // JXAQUEZVWEKTJGQFM4JIK0KU+YTMFPLL8J+N5MSPOFJHWOAG+9YHB7BWAHM36G == buffer@^5.4.3 : 버전 "5.4.3" "https://registry.yarnpkg.com/buffer/-/buffer-5.4.3.3fbc9c69eb713d323e3fc1a895ee0710c072115". 무결성 SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJQQGS4O/SNOEZG1F1KYAP9NU2JCUDPWZRSJTHMMMZG0H7BZKN4RNQPIMHUXWX2A == 종속성: Base64-JS "^1.0.2" IEEE754 "^1.1.4" IEEE754@^1.1.4 : 버전 "1.1.13" "https://registry.yarnpkg.com/ieee754/-/ieee754-1.1.13.tgz#ec168558e95AA181FD87D37F55C32BBCB6708B84" 무결성 SHA512-4VF7I2LYV/HAWERSO3XMLMKP5EZ83I+/CDLUXI/IGTS/O1SEJBNHTTNXZMRZFVOUQJ7LZQHKKHKKHKKKHKKHKKHKTGSFDLWZTG == INGORE@^5.1.4 : 버전 "5.1.4" "https://registry.yarnpkg.com/ignore/-/ignore-5.1.4.tgz#84b7b3dbe64552b6ef0eca99f6743dbec6d97adf를 해결했습니다." integrity sha512-MzbUSahkTW1u7JpKKjY7LCARd1fU5W2rLdxlM4kdkayuCwZImjkpluF9CM1aLewYJguPDqewLam18Y6AU69A8A==
It can be seen that it is quite similar to the package-lock.json file, and there are some differences:
package-lock.json uses json format, yarn.lock uses a custom formatyarn.lock The yarn.lock 중성자 종속성의 버전 번호는 고정되지 않았으므로 yarn.lock 만으로는 node_modules 디렉토리 구조를 결정할 수 없으며 package.json 파일과 조정해야합니다. 그리고 package-lock.json 결정하기 위해 하나의 파일 만 있으면됩니다.yarn 의 캐싱 전략은 npm v5 이전과 매우 유사합니다. 캐시 된 데이터의 디렉토리를보기 위해 명령 yarn cache dir 사용하십시오.
기본적으로
yarnprefer-online모드를 사용합니다. 즉, 네트워크 데이터가 먼저 사용되면 캐시 된 데이터가 요청됩니다.
이 기사를 읽은 후에는 다음과 같이 도움이되기를 바랍니다.
pacakge.json 의 세부 구성을 이해하여npm 의 버전 관리 메커니즘을 마스터하고 합리적으로 종속성을 구성 할 수 있습니다npm npm install 원리 package-lock.json 이해합니다