npm 5에서 생성한 package-lock.json 파일을 커밋합니까?

질문자 :rink.attendant.6

npm 5가 오늘 출시되었으며 package-lock.json 파일 생성을 통한 결정적 설치가 포함됩니다.

이 파일은 소스 제어에 보관되어야 합니까?

yarn.lock 및 composer.lock 과 유사하다고 가정하고 있는데, 둘 다 소스 제어에 유지되어야 합니다.

예, package-lock.json 은 소스 제어에 체크인하기 위한 것입니다. npm 5+를 사용하는 경우 명령줄에서 이 알림을 볼 수 있습니다 created a lockfile as package-lock.json. You should commit this file. npm help package-lock.json 에 따르면 :

package-lock.json node_modules 트리 또는 package.json 수정하는 모든 작업에 대해 자동으로 생성됩니다. 중간 종속성 업데이트에 관계없이 후속 설치에서 동일한 트리를 생성할 수 있도록 생성된 정확한 트리를 설명합니다.

이 파일은 소스 리포지토리에 커밋하기 위한 것이며 다양한 용도로 사용됩니다.

• 팀원, 배포 및 지속적인 통합이 정확히 동일한 종속성을 설치하도록 보장하는 종속성 트리의 단일 표현을 설명합니다.

• 사용자가 디렉토리 자체를 커밋하지 않고도 node_modules 이전 상태로 "시간 여행"할 수 있는 기능을 제공합니다.

• 읽을 수 있는 소스 제어 diff를 통해 트리 변경 사항을 더 쉽게 볼 수 있습니다.

• 그리고 npm이 이전에 설치된 패키지에 대해 반복되는 메타데이터 확인을 건너뛸 수 있도록 하여 설치 프로세스를 최적화합니다.

package-lock.json 에 대한 한 가지 주요 세부 사항은 게시할 수 없으며 최상위 패키지가 아닌 다른 위치에서 발견되는 경우 무시된다는 것입니다. 본질적으로 동일한 파일이지만 게시를 허용하는 npm-shrinkwrap.json과 형식을 공유합니다. 이는 CLI 도구를 배포하거나 프로덕션 패키지를 생성하기 위한 게시 프로세스를 사용하지 않는 한 권장되지 않습니다.

패키지의 루트에 package-lock.json 과 npm-shrinkwrap.json package-lock.json 은 완전히 무시됩니다.

vine77

예, 다음을 수행해야 합니다.

1. package-lock.json 커밋합니다.
2. CI와 로컬 개발 머신 모두에서 애플리케이션을 빌드할 때 npm install 대신 npm ci 를 사용하십시오.

npm ci 워크플로 에는 package-lock.json 합니다.

---

npm install 명령의 큰 단점은 예기치 않은 동작으로 package-lock.json 반면 npm ci 는 잠금 파일에 지정된 버전만 사용하고 오류를 생성합니다.

• package-lock.json 과 package.json 이 동기화되지 않은 경우
• package-lock.json 이 누락된 경우.

따라서 npm install 로컬로 실행합니다. 여러 개발자가 있는 대규모 팀에서는 package-lock.json 내에서 많은 충돌이 발생할 수 있으며 개발자는 대신 package-lock.json 을 완전히 삭제하기로 결정합니다.

그러나 프로젝트의 종속성이 여러 시스템에서 안정적인 방식으로 반복적으로 해결된다는 것을 신뢰할 수 있는 강력한 사용 사례가 있습니다.

package-lock.json 정확히 알 수 있는 것은 알려진 작업 상태입니다.

과거에는 무작위 종속성이 주요 업데이트를 가져왔기 때문에 언젠가 빌드가 실패하는 package-lock.json / npm-shrinkwrap.json / yarn.lock 파일이 없는 프로젝트가 있었습니다.

이 문제는 때때로 마지막 작업 버전이 무엇인지 추측해야 하므로 해결하기 어렵습니다.

새 종속성을 추가하려면 npm install {dependency} 를 계속 실행합니다. 업그레이드하려면 npm update {dependency} 또는 npm install ${dependendency}@{version} 하고 변경된 package-lock.json 커밋합니다.

업그레이드에 실패하면 마지막으로 알려진 작업 package-lock.json 되돌릴 수 있습니다.

---

npm 문서 를 인용하려면 :

생성된 패키지 잠금을 소스 제어에 커밋하는 것이 좋습니다. 이렇게 하면 팀, 배포, CI/지속적 통합 및 패키지 소스에서 npm install을 실행하는 모든 사람이 정확히 동일한 종속성 트리를 얻을 수 있습니다. 당신이 개발하고 있었다. 또한 이러한 변경 사항의 차이점은 사람이 읽을 수 있으며 npm이 node_modules에 대해 수행한 모든 변경 사항을 알려 주므로 이행 종속성이 업데이트, 호이스트 등인지 확인할 수 있습니다.

npm ci 대 npm install 의 차이점 과 관련하여 :

• 프로젝트에는 기존 package-lock.json 또는 npm-shrinkwrap.json이 있어야 합니다.
• 패키지 잠금의 종속성이 package.json의 종속성과 일치하지 않으면 npm ci 는 패키지 잠금을 업데이트하는 대신 오류와 함께 종료됩니다.
• npm ci 는 한 번에 전체 프로젝트만 설치할 수 있습니다. 이 명령으로 개별 종속성을 추가할 수 없습니다.
• node_modules 가 이미 있는 경우 npm ci 가 설치를 시작하기 전에 자동으로 제거됩니다.
• package.json 이나 어떤 package-lock에도 쓰지 않을 것입니다: 설치는 본질적으로 동결됩니다.

---

참고: 여기에 비슷한 답변을 게시했습니다.

k0pernikus

예, 체크인을 위한 것입니다. 고유한 커밋을 가져오도록 제안하고 싶습니다. 우리는 그것이 우리의 diff에 많은 노이즈를 추가한다는 것을 발견했습니다.

xer0x

예, 가장 좋은 방법은 체크인하는 것입니다(YES, CHECK-IN)

diff를 볼 때 많은 소음이나 충돌이 발생할 것이라는 데 동의합니다. 그러나 이점은 다음과 같습니다.

1. 모든 패키지의 동일한 버전을 보장합니다 . 이 부분은 다른 시간에 다른 환경에서 빌드할 때 가장 중요합니다. package.json 에서 ^1.2.3 을 사용할 수 npm install 이 개발 머신과 빌드 서버, 특히 간접 종속성 패키지에서 동일한 버전을 선택할 때마다 어떻게 보장할 수 있습니까? 글쎄, package-lock.json 이 그것을 보장할 것입니다. (잠금 파일을 기반으로 패키지를 설치하는 npm ci 의 도움으로)
2. 설치 프로세스를 개선합니다.
3. 그것은 새로운 감사 기능 npm audit fix 도움이 됩니다(감사 기능은 npm 버전 6부터라고 생각합니다).

Xin

git diff를 수행할 때 소음에 대해 불평하는 사람들에게:

 git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

내가 한 것은 별칭을 사용하는 것입니다.

 alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

전체 저장소(이를 사용하는 모든 사람)에 대한 diffs에서 package-lock.json을 무시하려면 다음을 .gitattributes 추가할 수 있습니다.

 package-lock.json binary yarn.lock binary

이렇게 하면 패키지 잠금 파일이 변경될 때마다 바이너리 파일 a/package-lock.json 및 b/package-lock.json이 다름을 표시하는 diff가 생성됩니다. 또한 일부 Git 서비스(특히 GitLab, GitHub 제외)도 제외됩니다. 이 작업을 수행할 때 온라인으로 볼 때 diff에서 이러한 파일(더 이상 10k 라인이 변경되지 않음!)

Raza

내 프로젝트에서 이 파일을 커밋하지 않습니다. 점은 무엇인가 ?

1. 생성된다
2. gitlab-ci.yml 빌드가 있는 gitlab의 SHA1 코드 무결성 오류의 원인입니다.

내가 나쁜 경험을 했기 때문에 libs에 대해 내 package.json에서 ^를 사용하지 않는 것은 사실이지만.

Deunz

예, 이 파일을 커밋할 수 있습니다. npm의 공식 문서에서 :

package-lock.json npm 이 node_modules 트리 또는 package.json 수정하는 모든 작업에 대해 자동으로 생성됩니다. 중간 종속성 업데이트에 관계없이 후속 설치에서 동일한 트리를 생성할 수 있도록 생성된 정확한 트리를 설명합니다.

이 파일은 소스 저장소[.]

Bablu Singh

package-lock.json 을 커밋하는 것이 표준 관행입니다.

package-lock.json 을 커밋하는 주된 이유는 프로젝트의 모든 사람이 동일한 패키지 버전에 있기 때문입니다.

장점:

• 엄격한 버전 관리를 따르고 주요 버전으로 자동 업데이트를 허용하지 않으면 패키지 잠금을 커밋하는 타사 패키지의 이전 버전과 호환되지 않는 변경 사항으로부터 자신을 보호할 수 있습니다.
• 특정 패키지를 업데이트하면 package-lock.json에서 업데이트되고 저장소를 사용하는 모든 사람이 변경 사항을 가져올 때 해당 특정 버전으로 업데이트됩니다.

단점:

• 풀 리퀘스트를 보기 흉하게 만들 수 있습니다. :)

npm install 은 프로젝트의 모든 사람이 동일한 패키지 버전에 있는지 확인하지 않습니다. npm ci 가 도움이 될 것입니다.

Nikhil Mohadikar

전역적으로 package-lock.json 비활성화

터미널에 다음을 입력하십시오.

 npm config set package-lock false

이것은 정말 마법처럼 나를 위해 일합니다.

Balogun Ridwan Ridbay

모든 대답은 "예"이지만 프로젝트에 따라 다릅니다.

package-lock.json에 대한 한 가지 주요 세부 사항은 게시할 수 없으며 최상위 패키지가 아닌 다른 위치에서 발견되는 경우 무시된다는 것입니다.

즉, 종속성을 위해 package-lock.json 을 npm에 게시 package-lock.json 을 사용하여 테스트 종속성의 버전을 잠그고 종속성을 빌드해야 합니다.

그러나 여러 패키지가 있는 프로젝트를 관리하기 위해 lerna 를 사용하는 경우 npm init 로 생성되는 각 하위 패키지가 아니라 package.json 넣어야 합니다. 당신은 다음과 같은 것을 얻을 것입니다 :

 .git lerna.json package.json package-lock.json <--- here packages/a/package.json packages/a/lib/index.js packages/b/package.json packages/b/lib/index.js

A-312

npm을 사용하는 것은 축소/불편화된 CSS/js를 생성하고 django 애플리케이션에서 제공하는 페이지에 필요한 자바스크립트를 생성하는 것입니다. 내 응용 프로그램에서 Javascript는 페이지에서 실행되어 애니메이션을 생성하고, 때때로 Ajax 호출을 수행하고, VUE 프레임워크 내에서 작업하거나 CSS로 작업합니다. package-lock.json에 package.json에 있는 항목에 대한 우선 제어가 있는 경우 이 파일의 버전이 하나 있어야 할 수 있습니다. 내 경험상 npm install에 의해 설치된 항목에 영향을 미치지 않거나 영향을 미치는 경우 내가 아는 한 배포하는 응용 프로그램에 부정적인 영향을 미치지 않았습니다. 나는 mongodb 또는 전통적으로 씬 클라이언트인 다른 애플리케이션을 사용하지 않습니다.

npm install이 이 파일을 생성하고 npm install이 앱을 실행하는 각 서버에서 배포 프로세스의 일부이기 때문에 repo에서 package-lock.json을 제거합니다. node와 npm의 버전 관리는 각각의 서버에서 수동으로 하고 있지만, 동일하다는 점에 주의합니다.

npm install 이 서버에서 실행되면 package-lock.json이 변경되고 서버의 repo에 의해 기록된 파일에 변경 사항이 있는 경우 다음 배포에서는 원본에서 새 변경 사항을 가져올 수 없습니다. 즉, pull이 package-lock.json에 적용된 변경 사항을 덮어쓰므로 배포할 수 없습니다.

package-lock.json에 무엇이 있는지 반영하지 않으면 명령을 실행할 때마다 npm이 불평할 것이기 때문에 로컬에서 생성된 package-lock.json을 repo에 있는 것으로 덮어쓸 수도 없습니다(하드 원본 마스터 재설정). npm 설치로 인한 node_modules, 따라서 배포가 중단됩니다. 이제 이것이 node_modules에 약간 다른 버전이 설치되었음을 나타내면 다시 한 번 문제를 일으키지 않았습니다.

node_modules가 리포지토리에 없으면(그렇지 않아야 함) package-lock.json을 무시해야 합니다.

누락된 부분이 있으면 댓글로 수정해 주시기 바랍니다. 하지만 이 파일에서 버전 관리를 가져왔다는 점은 의미가 없습니다. package.json 파일에는 버전 번호가 있으며 이 파일은 npm install이 발생할 때 패키지를 빌드하는 데 사용되는 파일이라고 가정합니다. 제거할 때 npm install은 다음과 같이 불평합니다.

 jason@localhost:introcart_wagtail$ rm package.json jason@localhost:introcart_wagtail$ npm install npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

빌드가 실패하지만 node_modules를 설치하거나 npm을 적용하여 js/css를 빌드할 때 package-lock.json을 제거해도 불만이 없습니다.

 jason@localhost:introcart_wagtail$ rm package-lock.json jason@localhost:introcart_wagtail$ npm run dev > introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail > NODE_ENV=development webpack --progress --colors --watch --mode=development 10% building 0/1 modules 1 active ...

MagicLAMP

package-lock.json을 소스 코드 버전 제어에 커밋한다는 것은 프로젝트가 package.json에 정의된 것과 일치하거나 일치하지 않을 수 있는 특정 버전의 종속성을 사용한다는 것을 의미합니다. 종속성에는 보다시피 캐럿(^) 및 물결표(~)가 없는 특정 버전이 있지만, 이는 종속성이 최신 버전으로 업데이트되지 않음을 의미합니다. npm install은 현재 버전의 Angular에 필요한 것과 동일한 버전을 선택합니다.

참고: CI 중에 업데이트할 종속성에 캐럿(^) 및 물결표(~)를 추가한 경우 package-lock.json을 커밋하는 것이 좋습니다.

MedElmaachi

출처 : http:www.stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5