npm 5에서 만든 package-lock.json 파일을 커밋합니까?

npm 5에서 만든 package-lock.json 파일을 커밋합니까?

---

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.jsonnpm이 node_modules트리 또는을 수정하는 모든 작업에 대해 자동으로 생성됩니다 package.json. 생성 된 정확한 트리를 설명하므로 후속 설치에서 중간 종속성 업데이트에 관계없이 동일한 트리를 생성 할 수 있습니다.

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

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

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

• 읽을 수있는 소스 제어 diff를 통해 트리 변경 사항을 더 잘 볼 수 있도록합니다.

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

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

package-lock.json와 둘 다 npm-shrinkwrap.json패키지의 루트에 package-lock.json있으면 완전히 무시됩니다.

---

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

---

예, 가장 좋은 방법은 체크인하는 것입니다 (예, 체크인).

차이점을 볼 때 많은 소음이나 갈등이 발생할 것이라는 데 동의합니다. 그러나 이점은 다음과 같습니다.

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

---

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

1. 생성되었습니다
2. gitlab-ci.yml 빌드를 사용하는 gitlab에서 SHA1 코드 무결성 오류의 원인입니다.

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

---

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'"

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

package-lock.json binary
yarn.lock binary

이로 인해 패키지 잠금 파일이 변경 될 때마다 "바이너리 파일 a / package-lock.json 및 b / package-lock.json이 다릅니다. 또한 일부 Git 서비스 (특히 GitLab, GitHub 제외)는 제외됩니다. 이 파일을 온라인으로 볼 때 diff에서이 파일 (10k 줄이 더 이상 변경되지 않았습니다!)

---

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

1. 커밋합니다 package-lock.json.
2. npm cinpm installCI와 로컬 개발 머신 모두에서 애플리케이션을 빌드 할 때 대신 사용

npm ci워크 플로우 요구 a의 존재를 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대신 완전히 삭제하기로 결정합니다 .

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

A로부터 package-lock.json당신은 정확하게 얻을 : 알려진 - 투 - 작업 상태.

In the past, I had projects without package-lock.json / npm-shrinkwrap.json / yarn.lock files whose build would fail one day because a random dependency got a breaking update.

Those issue are hard to resolve as you sometimes have to guess what the last working version was.

If you want to add a new dependency, you still run npm install {dependency}. If you want to upgrade, use either npm update {dependency} or npm install ${dependendency}@{version} and commit the changed package-lock.json.

If an upgrade fails, you can revert to the last known working package-lock.json.

---

To quote npm doc:

It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on. Additionally, the diffs from these changes are human-readable and will inform you of any changes npm has made to your node_modules, so you can notice if any transitive dependencies were updated, hoisted, etc.

And in regards to the difference between npm ci vs npm install:

• The project must have an existing package-lock.json or npm-shrinkwrap.json.
• If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
• npm ci can only install entire projects at a time: individual dependencies cannot be added with this command.
• If a node_modules is already present, it will be automatically removed before npm ci begins its install.
• It will never write to package.json or any of the package-locks: installs are essentially frozen.

---

Note: I posted a similar answer here

---

Yes, you can commit this file. From the npm's official docs:

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This file is intended to be committed into source repositories[.]

---

Disable package-lock.json globally

type the following in your terminal:

npm config set package-lock false

this really work for me like magic

---

Yes, it's a standard practice to commit package-lock.json

The main reason for committing package-lock.json is that everyone in the project is on the same package version.

Pros:-

• Everyone in the project will be on the same package version, all you have to do is

  npm install

• If you follow strict versioning and don't allow updating to major versions automatically to save yourself from backward incompatible changes in third-party packages committing package-lock helps a lot.

Cons:-

• It can make your pull requests look ugly :)'

---

My use of npm is to generate minified/uglified css/js and to generate the javascript needed in pages served by a django application. In my applications, Javascript runs on the page to create animations, some times perform ajax calls, work within a VUE framework and/or work with the css. If package-lock.json has some overriding control over what is in package.json, then it may be necessary that there is one version of this file. In my experience it either does not effect what is installed by npm install, or if it does, It has not to date adversely affected the applications I deploy to my knowledge. I don't use mongodb or other such applications that are traditionally thin client.

I remove package-lock.json from repo because npm install generates this file, and npm install is part of the deploy process on each server that runs the app. Version control of node and npm are done manually on each server, but I am careful that they are the same.

When npm install is run on the server, it changes package-lock.json, and if there are changes to a file that is recorded by the repo on the server, the next deploy WONT allow you to pull new changes from origin. That is you can't deploy because the pull will overwrite the changes that have been made to package-lock.json.

You can't even overwrite a locally generated package-lock.json with what is on the repo (reset hard origin master), as npm will complain when ever you issue a command if the package-lock.json does not reflect what is in node_modules due to npm install, thus breaking the deploy. Now if this indicates that slightly different versions have been installed in node_modules, once again that has never caused me problems.

If node_modules is not on your repo (and it should not be), then package-lock.json should be ignored.

If I am missing something, please correct me in the comments, but the point that versioning is taken from this file makes no sense. The file package.json has version numbers in it, and I assume this file is the one used to build packages when npm install occurs, as when I remove it, npm install complains as follows:

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'

and the build fails, however when installing node_modules or applying npm to build js/css, no complaint is made if I remove 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 ...

참고URL : https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5