이것은 ci / cleaninstall이 하려는 것이 아닙니다. 현재 동작이 정확합니다. 사용하려는 것은 npm shrinkwrap 입니다.

node_modules _folder_ 는 삭제하지 않고 _contents_ 는 삭제하지 않도록 업데이트를 추가했습니다(해당 게시물에서 원래 요청한 대로). npm ci 명령의 목적은 깨끗한 상태에서 시작하기 위해 모든 것을 삭제하는 것입니다. 이전 node_modules를 유지하려면 npm i 합니다.

답장해주셔서 감사합니다! 답변이 늦어 죄송합니다. npm shrinkwrap 살펴보았지만 지속적인 통합을 위해 빌드 서버에서 실행하기 위한 것입니까? 이 명령을 실행하면 내 package-lock.json 이 npm-shrinkwrap.json 되지만 CI 중에 무엇을 실행해야 합니까? npm install 증분 업데이트를 하시겠습니까? 또는 npm ci 실행해야 하지만 모든 패키지가 다시 삭제됩니다. -(내가 찾고 있는 것은 증분 업데이트를 수행하지만 package-lock.json 있는 것을 정확히 설치하는 명령입니다.

@claudahdz; 내 이해는 CI 중에 npm install 를 실행하면 package-lock.json 이 업데이트되고 몇 주 후에 동일한 빌드를 실행하면 다른 패키지가 설치된다는 것을 의미할 수 있다는 것입니다. 틀린 말인가요?

Ps npm ci 는 Continuous Integration의 약자라고 생각

여기 참조: https://github.com/npm/npm/issues/20104#issuecomment -403321557

현재 동작은 Docker 컨테이너 내부에서 npm ci 있고(지속적 통합에 매우 일반적임) node_modules 에 바인드 마운트가 있는 경우 문제가 됩니다.

다음 오류가 발생합니다.

webpack_1   | npm ERR! path /var/www/project/docker-config/webpack-dev-devmode/node_modules
webpack_1   | npm ERR! code EBUSY
webpack_1   | npm ERR! errno -16
webpack_1   | npm ERR! syscall rmdir
webpack_1   | npm ERR! EBUSY: resource busy or locked, rmdir '/var/www/project/docker-config/webpack-dev-devmode/node_modules'

그러면 Docker 컨테이너가 중단됩니다.

--no-delete 플래그가 있거나 npm ci 가 node_modules 의 _contents_를 삭제할 수 있지만 디렉토리 자체는 삭제하지 않는 것이 좋습니다.

ci = 새로 설치

예상됩니다. 잠금 파일과 함께 일반 npm i 를 사용하지 않는 이유는 무엇입니까?

--no-delete 플래그가 있거나 npm ci가 node_modules의 내용을 삭제할 수 있지만 디렉토리 자체는 삭제할 수 없는 경우가 좋습니다.

rm -rf node_modules/* && npm i

ci = 새로 설치

예상됩니다. 잠금 파일과 함께 일반 npm i를 사용하지 않는 이유는 무엇입니까?

...때문에: https://docs.npmjs.com/cli/ci.html

이 명령은 테스트 플랫폼, 지속적 통합 및 배포와 같은 자동화된 환경 또는 종속성을 새로 설치하려는 모든 상황에서 사용한다는 점을 제외하고 npm-install과 유사합니다. 특정 사용자 지향 기능 을 훨씬 빠를 수 있습니다 . 또한 일반 설치보다 더 엄격하므로 대부분의 npm 사용자가 점진적으로 설치하는 로컬 환경으로 인해 발생하는 오류나 불일치를

더 빠른 설치와 깨끗한 슬레이트 접근 방식은 위에서 언급한 것과 같은 CI 환경에 이상적입니다.

rm -rf node_modules/* && npm i

이것이 내가 지금하는 일이지만 npm ci 를 사용하려는 욕구는 위를 참조하십시오.

npm ci 가 디렉토리 자체가 아니라 node_modules 의 내용 을 제거하도록 하는 구성 플래그를 요청하는 RFC를 제출하는 것이 합리적으로 보입니다. 이것은 node_modules 디렉토리를 선택적으로 무시하도록 Dropbox를 설정했다는 점에서 저에게도 문제입니다. 그러나 삭제하면 해당 선택적 설정이 사라지고 다음에 node_modules 생성되면 동기화됩니다.

npm ci 가 디렉토리 자체가 아니라 node_modules 의 _contents_를 제거하도록 하는 구성 플래그를 요청하는 RFC를 제출하는 것이 합리적으로 보입니다. 이것은 node_modules 디렉토리를 선택적으로 무시하도록 Dropbox를 설정했다는 점에서 저에게도 문제입니다. 그러나 삭제하면 해당 선택적 설정이 사라지고 다음에 node_modules 생성되면 동기화됩니다.

이것은 또한 npm이 dir(OSX 스포트라이트 및 기타의 경우)을 무시하도록 파일을 생성할 수 있도록 하는 또 다른 문제가 설명된 것이 아닙니까? 이 기능을 필요로 하는 다른 사람들도 있었다고 생각합니다.

ci = 새로 설치

예상됩니다. 잠금 파일과 함께 일반 npm i 를 사용하지 않는 이유는 무엇입니까?

npm i 는 훌륭하지만 잠금 파일을 변경하지 않는 경우에만 가능합니다. npm i 중에 package-lock.json이 업데이트되는 것을 보았습니까? 아니면 발생하지 않아야 합니까?

이 기능을 지원합니다. 명시된 바와 같이 npm i 는 package-lock.json을 수정합니다. 플래그는 이상적인 솔루션이 될 것입니다.

마찬가지로 깃발이 좋을 것입니다.

이 기능을 지원합니다. 명시된 바와 같이 npm i 는 package-lock.json을 수정합니다. 플래그는 이상적인 솔루션이 될 것입니다.

그렇다면 npm i 플래그를 추가하지 않겠습니까? 이것은 내 의미에서 ci = clean install 에 대해 그다지 의미가 없기 때문입니다.

"새로 설치"의 어떤 부분이 상위 node_modules/ 디렉토리를 그대로 유지하는 것과 호환되지 않습니까(실제 내용을 새로 설치하는 동안)?

이 경우 CI가 지속적인 통합을 의미하지 않는다는 것을 알고 있습니다. 그러나 문서에서 명확하게 알 수 있듯이 새로 설치는 지속적 통합 환경에서 종종 매우 유용합니다.

이 명령은 테스트 플랫폼, 지속적 통합 및 배포와 같은 자동화된 환경 또는 종속성을 새로 설치하려는 모든 상황에서 사용한다는 점을 제외하면 npm-install과 유사합니다. 특정 사용자 지향 기능을 건너뛰면 일반 npm 설치보다 훨씬 빠를 수 있습니다. 또한 일반 설치보다 더 엄격하므로 대부분의 npm 사용자가 점진적으로 설치하는 로컬 환경으로 인해 발생하는 오류나 불일치를 포착하는 데 도움이 될 수 있습니다.

npm ci 는 특히 자동화된 환경에서 사용하기 위한 것으로, 여러 번 이는 Docker 기반 설정을 의미합니다.

node_module/ 디렉토리를 삭제하는 동작은 이 스레드에서 언급한 이유로 Docker 기반 설정에서 문제가 됩니다.

따라서 우리는 이 명령을 의도된 목적과 환경에 유용하게 만들 수 있는 옵션을 요청하고 있습니다.

이 기능을 지원합니다. 명시된 바와 같이 npm i 는 package-lock.json을 수정합니다. 플래그는 이상적인 솔루션이 될 것입니다.

그렇다면 npm i 플래그를 추가하지 않겠습니까? 이것은 내 의미에서 ci = clean install 에 대해 그다지 의미가 없기 때문입니다.

이 질문을 해야 합니다. npm install 와 npm ci 사이의 다른 차이점이 있다면 npm install 에서 두 옵션을 모두 사용할 수 없는 이유는 무엇입니까? ci 필요 npm install --no-update-package-lock --clean-node-modules 와 같은 별칭이 됩니다.

node_module/ 디렉토리를 삭제하는 동작은 이 스레드에서 언급한 이유로 Docker 기반 설정에서 문제가 됩니다.

제 생각에 이것은 이미지가 빌드될 때 한 번만 발생해야 합니다. 그 이후에는 개발 중에 npm i 사용해야 합니다.

ci 는 npm install --no-update-package-lock --clean-node-modules 와 같은 별칭이 되어야 합니다.

개인적으로 일반 npm i 명령에 대한 추가 플래그가 더 합리적입니다.

나는 무관심하고 솔직히 ci 여야한다는 구체적인 주장을하기에는 js 토지가있는 n00b가 너무 많습니다. 내가 아는 것은 package-lock.json 업데이트해서는 안된다는 것입니다. node_modules 제거하면 안 됩니다.

npm ci 는 잠금 파일을 업데이트하지 않고 잠금 파일에서 설치합니다. 이것은 이전에 이 사람들이 rm -rf node_modules 대해 조언을 받고 npm i 다시 실행하기 때문에 새로 설치하기 위해 도입되었습니다. 그리고 faik 사람들은 잠금 파일을 변경하지 않고 잠금 파일에서 설치하기를 원했습니다.

그래서 npm ci 가 탄생했습니다. 또한 설치된 패키지 목록과 트리 및 기타 몇 가지 사항을 건너뜁니다.

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable 참조

특정 사용 사례를 다룹니다.

다른 사용 사례를 들어 우리는 새로운 플래그를 추가해야합니다 npm i 우리는 또한 에뮬레이트 할 수있는을 npm ci 에 대한 플래그보다 더 유연하고 더 나은 솔루션 인 npm ci 여전히 포함해야한다 현재 사용 사례 imho. 여기서 사용자가 요청하는 것은 yarn install --frozen-lockfile 또는 yarn --frozen-lockfile 와 약간 유사합니다.

그렇지 않으면 플래그가 npm ci , npm i 등으로 분산되어 좀 더 어려워집니다(문서, 코드, ...). 적어도 이것이 내가 생각하는 것입니다. npm i 넣어 보겠습니다. 더 강력하고 유연한 방법으로 동작을 구성할 수 있습니다.

다른 사용 사례의 경우 현재 사용 사례 imho만 포함해야 하는 npm ci에 대한 플래그보다 더 유연하고 더 나은 솔루션인 npm ci를 에뮬레이트할 수도 있는 npm i에 새 플래그를 추가해야 합니다. 여기서 사용자가 요청하는 것은 yarn install --frozen-lockfile 또는 yarn --frozen-lockfile 과 약간 유사합니다.

npm i 기능이 추가되면 매우 기쁠 것입니다. 원본 게시물을 업데이트해야 하나요?

npm ci 는 잠금 파일을 업데이트하지 않고 잠금 파일에서 설치합니다. 이것은 이전에 이 사람들이 rm -rf node_modules 대해 조언을 받고 npm i 다시 실행하기 때문에 새로 설치하기 위해 도입되었습니다. 그리고 faik 사람들은 잠금 파일을 변경하지 않고 잠금 파일에서 설치하기를 원했습니다.

그래서 npm ci 가 탄생했습니다. 또한 설치된 패키지 목록과 트리 및 기타 몇 가지 사항을 건너뜁니다.

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable 참조

특정 사용 사례를 다룹니다.

다른 사용 사례를 들어 우리는 새로운 플래그를 추가해야합니다 npm i 우리는 또한 에뮬레이트 할 수있는을 npm ci 에 대한 플래그보다 더 유연하고 더 나은 솔루션 인 npm ci 여전히 포함해야한다 현재 사용 사례 imho. 여기서 사용자가 요청하는 것은 yarn install --frozen-lockfile 또는 yarn --frozen-lockfile 와 약간 유사합니다.

rm -rf node_modules/* "청소"에 해당하지 않는 이유는 무엇입니까? 여기에서 묻는 기능은 npm ci에 있는 기능과 매우 유사합니다. 제 생각에는 npm ci의 전체 동작을 npm i로 가져오는 대신 rm -rf node_modules 대신 rm -rf node_modules/* 를 사용하도록 npm ci에 플래그를 추가하는 것이 더 합리적입니다.

BTW 이 문제는 더 많은 관심을 받아야 하고 유지 관리자는 이에 대한 의견과 계획을 발표해야 합니다. docker 사용은 기본적으로 npm ci의 주요 사용 사례 중 하나인 CI(지속적 통합)에서 기본적으로 항상 사용됩니다!

이 리포지토리의 문제가 아니라 이 변경 사항에 대한 RFC를 여십시오.

혼동을 피하기 위해 이 문제의 이름을 "npm CI에서 node_modules dir을 제거하는 대신 비어 있음"으로 이름을 바꾸겠습니다.

이 문제의 의도는 node_modules 폴더를 삭제하거나 폴더의 내용만 삭제하는 것이 아닙니다. 항상 node_modules 의 내용을 보존하지만 최신 상태이고 package-lock.json 와 동기화되어 있는지 확인하십시오. 따라서 package-lock.json 를 준수하는 증분 업데이트입니다.

내가 틀렸을 수도 있지만 여기에 두 가지 문제가 있다고 생각합니다. 누군가가 폴더를 완전히 삭제하는 대신 node_modules의 내용만 삭제하는 것에 대해 다른 문제 또는 RFC를 시작할 수 있습니까? 아니면 내가 뭔가를 놓치고 있습니까?

@Zenuka npm CI가 빠르고 존재하는 전체 이유는 기존 node_modules 디렉토리를 무시하기 때문이므로 변경될 가능성은 거의 없습니다.

우리의 사용 사례에서는 nodes_modules 폴더가 최신인지 확인하는 것이 더 빠를 것이라고 생각합니다. 그렇지 않은 경우 업데이트해야 하는 패키지만 업데이트합니다(예 npm i ). 일부 전용 VM이 빌드 에이전트로 실행 중이므로 빌드를 실행하고 nodes_modules 폴더와 모든 내용을 유지합니다. 모든 것을 삭제하고 다시 설치하는 것보다 빠를 것입니다. package.json 또는 package-lock.json 에 대한 변경보다 훨씬 더 많은 코드 변경에 대한 빌드 및 테스트를 실행합니다.

우리의 사용 사례에서는 nodes_modules 폴더가 최신인지 확인하는 것이 더 빠를 것이라고 생각합니다.

글쎄, 이것은 (패키지 트리의 계산) 가장 시간이 많이 걸리는 것입니다. 이 검사는 npm ci 정말 느리게 만듭니다.

빌드를 실행하고 nodes_modules 폴더와 모든 내용을 유지하는 것이 모든 것을 삭제하고 다시 설치하는 것보다 더 빨라야 합니다.

이유는 아마하지, 그건 npm ci 무엇을하는 건너 뜀 소개 된 npm i (패키지 트리 확인) 않습니다를.

@Zenuka npm install 이미 원하는 것을 할 수 있는 가장 빠른 방법입니다. npm ci 에는 단 하나의 목적이 있습니다. 즉, diff를 계산할 필요가 없도록 node_modules를 삭제하여 더 빠르게 수행하십시오.

아마도 그렇지 않을 것입니다. 그래서 npm i가 하는 일을 건너뛰는 npm ci가 도입되었습니다(패키지 트리 확인).

나는 이것을 내 컴퓨터 에서만 테스트했지만(물론 좋은 측정은 아님) 최신 node_modules 폴더에서 npm install 실행은 10초 이내에 완료됩니다. npm ci 데 몇 분이 걸립니다. 다른 결과를 기대하시겠습니까?

나는 npm install 잠금 파일을 고정하는 플래그를 추가 하라는 당신의

package-lock.json 이 실제로 존재하는지 확인하는 것은 Windows에서도 매우 빠릅니다. https://github.com/fuzzykiller/verify-node-modules를 참조

node_modules 에 다른 것이 없는지 확인하는 것은 확실히 조금 더 오래 걸리지만 여전히 1초 미만일 것입니다.

이를 기반으로 npm ci 의 증분 버전을 쉽게 만들 수 있습니다. 트리는 이미 계산되어 package-lock.json 저장됩니다.

또한, 기본적으로 유일한 이유는 npm ci 존재는에 무엇이 설치하는 것입니다 package-lock.json . npm install 처럼 깜짝 업그레이드를 몰래 하지 않고 말이죠.

내 2센트, 나는 개인적으로 우리 인프라를 npm ci 로 바꿨습니다. 이전 태그 npm i 가 잠금 파일을 준수하지 않는 것도 지겹기 때문입니다. 문제의 큰가에 플래그를 추가하는 것을 npm ci 수준 (.. 내가 얻을 수있는 그 clean install 의 그것에게 일을)를 npm i REALLLLLYLYY이 플래그를 필요로한다. 그러나 나는 이것을 조사한 것을 기억하고 npm 팀이 사람들이 npm ci 사용하도록 제안한 2년 이상된(그리고 여전히 열려 있는) npm i 에 대한 문제 스레드도 있었습니다. lol... this 사람들이 과거에 npm을 포기하고 원사로 간 이유입니다.

다시 또 다른 개발자 관점

나는 모듈을 유지할 가능성을 추가하는 데 투표했습니다 :heavy_plus_sign: .

+1 - @phyzical 과 @fuzzykiller가 말했듯이 npm install 와 npm ci 사이에는 node_modules를 유지하지만 여전히 package-lock.json 존중하고 더 빠르게 실행되는 "스위트 스팟"이 없습니다.
가능한 한 빨리 실행하십시오 - node_modules에 이미 존재하는 package-lock의 종속성을 찾은 다음 누락된 다른 모든 것을 설치하십시오. 업그레이드나 삭제가 없습니다.

개인적으로 나는 그것이 어느 쪽이 걱정하지 않는다 ( install 또는 ci )이있을 것입니다,하지만 같은이 소리의 모든 npm install 단지 모든과에 대한 플래그가 있어야 npm ci 는 별도의 명령어가 아니어도 됩니다.

npm ci 가 원래 이 문제가 제기하는 동일한 문제에 대한 솔루션 으로 선전되었다는 점을 감안할 때 이는 다소 실망스럽습니다.

사람들의 숫자가 원했다는 것을 원래 행동 npm install 상기보고했다 package-lock.json 대신 package.json . 우리는 npm install 에 플래그를 지정하여 해당 동작을 켜고 싶었습니다. 대신 얻은 것은 npm ci . 그 이유는 다음과 같습니다.

package.json은 프로젝트의 필수 종속성을 설명합니다. 현재 잠금 파일이 이를 충족할 수 없으면 잠금 파일이 양보해야 합니다. lockfile의 목적은 package.json을 폐기하는 것이 아니라 여러 시스템에서 반복 가능한 설치를 만드는 것입니다.

알았어. npm install 는 해당 옵션에 적합한 위치가 아니라 npm ci 입니다. npm ci 제외하고는 원래 문제에 대한 유용한 솔루션이 되지 않도록 하는 추가 동작( node_modules 폴더 지우기)을 추가합니다. 그리고 지금 npm ci 에 플래그가 있을 수 없는 이유는 다음과 같습니다.

ci = 새로 설치

예상됩니다. 잠금 파일과 함께 일반 npm i를 사용하지 않는 이유는 무엇입니까?

어느... 좋아. 플래그가 어디에 추가되는지는 별로 신경 쓰지 않습니다. 나는 인터페이스 이면의 기본 철학에 대해 이해관계가 없습니다. 그러나 플래그를 어딘가에 추가할 수 있습니까?

젠장, 사람들이 완전히 분리된 제3의 명령을 원한다 해도 나는 이의를 제기하지 않을 것이다. 내가 신경쓰는 유일한 것은 일반 설치를 위한 package-lock.json 존중에 대한 이 대화가 시작된 지 3년이 지났지만 여전히 우리가 원래 요청했던 동작을 얻을 수 있는 방법이 없다는 것입니다.

내 직장에서 우리는 패키지에 대한 마이너 및 bugfix 버전 업데이트에서 버그를 보았습니다. 우리는 의도적인 패키지 업그레이드 중에만 이러한 버그를 찾고자 하며 개발 환경이 프로덕션 환경과 다른 패키지 버전을 사용하는 것을 원하지 않습니다. 일관성이 매우 중요합니다. 어떤 사람은 전화를하고 싶어하거나 누군가가 넣어 원하는 어디든지, 우리는 또한을 통해 앉아 우리를 필요로하지 않습니다 잠금 파일에서 패키지를 얻을 수있는 빠른 방법 원하는 node-gyp 이미 설치된 모듈마다 우리에 대한 빌드를 명령을 실행합니다.

이것이 내가 완벽한 세상에서 작동하는 방법입니다.

• npm install - 오늘과 같은 동작
• npm install --from-lockfile - 잠금 파일에서 설치( ci 처럼)
• npm install --clean - npm install 와 동일한 동작이지만 node_modules 콘텐츠 삭제
• npm ci - npm install --from-lockfile --clean 대한 별칭

@jdussouillez 이것이 정확히 일어나야 하는 일입니다. 아주 잘 말했다! 이 솔루션이 적용되는 것을 보고 싶습니다.

CI 파이프라인에 대한 속도와 일관성 사이에서 결정해야 하는 이 문제에 직면하는 것은 지속적으로 실망스럽습니다. 나는 지난 2개월 동안 여러 가지 이유로 3~4번 문제를 겪었다.

이 기능은 Azure Pipelines 및 기타 클라우드 아키텍처에 유용합니다.

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#tip

npm ci는 일관되고 반복 가능한 모듈 집합이 사용되도록 node_modules 폴더를 삭제하므로 npm ci를 호출할 때 node_modules 캐싱을 피해야 합니다.

닫기: @claudiahdz가 언급했듯이 npm ci 가 더 이상 node_nodules 폴더 자체를 제거하지 않고 내용만 제거하는 이 동작에 대한 수정 사항을 제공했습니다(참조 https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09). 이것은 7월 21일에 [email protected] 로 배송되었으며(참조 https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21) npm@7 에서 동일한 경험.

npm ci 또는 다른 명령에 별도의 문제가 있는 경우 문제 템플릿 중 하나를 사용하여 버그를 신고 하세요 .

참고사항...

@jdussouillez 피드백에 감사드립니다. 잠금 파일에서 직접 설치하는 경우 --package-lock-only 플래그(예: npm install --package-lock-only )를 사용하여 오늘 설치할 수 있습니다. --clean 플래그를 install 에 추가하는 것과 관련하여 이것이 많은 가치를 추가한다고 느끼지는 않지만 내가 틀릴 수 있습니다. 이에 대해 강하게 느끼신다면 https://github.com/npm/rfcs 에서 RFC를 제출해 주시기

@claudiahdz가 거의 1년 전에 npm ci 동작이 폴더 자체가 아니라 node_modules 콘텐츠를 삭제하도록 하는 것과 관련이 있는 것 같습니다. 예를 들어 도커 컨테이너에 마운트할 때 편리하지만 최종 결과는 변경되지 않습니다. npm ci 는 모든 종속성을 처음부터 다운로드

npm install --package-lock-only 사용하면 원래 문제와 정확히 반대되는 작업을 수행하는 것 같습니다(제가 올바르게 이해한 경우). package-lock.json 파일만 업데이트하고 종속성을 다운로드하지 않습니다.

내가 원래 문제에서 이해한 것은 node_modules 폴더의 현재 상태와 package-lock.json 파일을 가져오고 node_modules 를 얻기 위해 필요한 패키지만 다운로드하는 옵션이 있어야 한다는 것입니다. package-lock.json 와 일치하는 node_modules 버전. 따라서 매번 모든 것을 다운로드하는 것보다 훨씬 빠르며 결국 동일한 결과를 얻을 수 있습니다.

npm install 이미 항상 하는 일 아닌가요?

npm install 이미 항상 하는 일 아닌가요?

AFAIK -
npm install 는 package.json 파일에 따라 모든 종속성을 해결하고( package-lock.json 무시), 현재 node_modules 폴더에 있는 것과 비교하고 요구 사항에 맞게 다운로드해야 하는 종속성. 그에 따라 package-lock.json 도 업데이트됩니다.

그것은 확실히 lockfile을 무시하지 않습니다 - 단지 npm ci 가 하지 않는 기존 트리를 고려합니다.

당신이 맞습니다. 죄송합니다.
제가 잘못 기억했습니다(과거에는 그런 행동이었을까요?). 간단한 dep 트리로 몇 가지 테스트를 수행했으며 package-lock.json 파일이 있을 때 npm i 는 지정된 버전을 정확히 설치하고 아무 것도 변경하지 않습니다. 이것은 내가 찾던 행동이었으므로 만족합니다. 👍
비공개 문제로 글을 올려 죄송합니다.

내 원래 요청은 실제로 ATGardner가 설명한 내용이었습니다.

내가 원래 문제에서 이해한 것은 node_modules 폴더의 현재 상태와 package-lock.json 파일을 가져오고 node_modules 를 얻기 위해 필요한 패키지만 다운로드하는 옵션이 있어야 한다는 것입니다. package-lock.json 와 일치합니다. 따라서 매번 모든 것을 다운로드하는 것보다 훨씬 빠르며 결국 동일한 결과를 얻을 수 있습니다.

npm install 나의 경험은 때때로 package-lock.json 파일을 업데이트한다는 것입니다. 나는 이것을 잠시 동안 업데이트하지 않고 git pull 및 npm i 실행한 저장소로 오늘 아침에 이것을 다시 테스트했습니다. 이번에는 실제로 어떤 버전도 업데이트하지 않았고 일부 종속성과 추가 패키지만 추가했습니다.

불행히도 이것은 개인 저장소이지만 재현 가능한 공개 저장소로 다른 누군가가 있습니까? 여러 커밋이 있고 그 사이를 전환하면 npm install 가 package-lock.json 를 업데이트합니까?

나는 커밋하지 않을 경우 관련 일부 사용자 오류가있을 수 실현 package-lock.json 업데이트 할 때 package.json 하지만 내 동료들이 업데이트해야한다고 알고 package-lock.json 뿐만 아니라. 나는 이것을 조사할 것이다.

npm i 가 package-lock.json 파일을 변경하도록 하는 간단한 예를 얻을 수 없습니다. 하지만 좀 더 시도해 보겠습니다.

경우 npm i 항상에 지정된 동일한 버전의 다운로드 끝 package-lock.json 그것에서 할 수있는만큼 유지하면서, 현재 node_modules , 내가 왜 지금까지 실행해야합니다 npm ci ? 다시 다운로드하기 전에 모든 것을 삭제하면 어떤 이점이 있습니까?

https://docs.npmjs.com/cli/v6/commands/npm-ci#description 참조

토론의 장이 되지 못한 점 다시 한 번 사과드립니다. 더 좋은 곳이 또 있을까요?

나는 아직도 이해하지 못한다. 만약의 상태 node_modules 실행 후 npm i 정확히 일치 package-lock.json , 그리고 상태를 node_modules 실행 후 npm ci 동일한있다 최종 결과 - 거의 모든 시나리오에서 구축 중인 컴퓨터에 이미 폴더에 일부/대부분의 종속성이 있다고 가정하면 npm i 가 더 빠르지 않을까요? 이미 로컬에 있는 것을 다운로드하지 않고 필요한 버전과 일치합니다.

왜 모든 것을 처음부터 삭제하고 다운로드할까요?

아니요, npm ci 는 deptree를 다시 확인하지 않기 때문에 여전히 더 빠르며 일부 콘솔 출력이 완료되지 않습니다.

왜 모든 것을 처음부터 삭제하고 다운로드할까요?

문제를 방지하기 위해 ci 는 배포와 같은 특정 환경을 위한 것입니다.
문서에서 이미 차이점을 언급하고 있다고 생각합니다.

특정 사용자 지향 기능을 건너뛰면 일반 npm 설치보다 훨씬 빠를 수 있습니다. 또한 일반 설치보다 더 엄격하므로 대부분의 npm 사용자가 점진적으로 설치하는 로컬 환경으로 인해 발생하는 오류나 불일치를 포착하는 데 도움이 될 수 있습니다.

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable 도

npm ci 는 여전히 빠릅니다.

따라서 npm i 사용할 때 현재 node_modules 를 읽고 어떤 패키지를 다운로드해야 하는지 파악하는 데 걸리는 시간은 npm에서 모든 패키지를 실제로 다운로드하는 데 걸리는 시간보다 훨씬 큽니다. 서버? 그것을 측정하는 실제 실험을 보고 싶습니다.

그리고 나는 또한 이 단락을 이해하지 못한다 -

npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.

npm i 를 실행하는 것은 package-lock.json 파일의 정확한 버전을 사용하고 실행 후 node_modules 의 상태는 실행될 상태와 동일하다는 결론을 내리지 않았습니까? npm ci 실행한 후입니까? 따라서 빌드는 그대로 재현할 수 있습니다.

업데이트:

나는 다음과 같은 테스트를 했다 -
새로운 create-react-app 프로젝트를 만들었습니다. 초기화가 완료된 후 package.json 에는 7개의 직접 종속성이 있고 package-lock.json 에는 1982개의 패키지가 포함되어 있습니다.
이 상태에서( node_modules 에는 모든 종속성이 포함됨) - npm i 하면

real    0m2.548s
user    0m2.659s
sys     0m0.182s

단일 패키지 폴더( node_modules/babel-eslint )를 삭제한 다음 npm i 다시 실행하면

real    0m3.295s
user    0m3.543s
sys     0m0.434s

누락된 종속성을 다시 다운로드하려면

전체 node_moduels 폴더를 삭제하고 npm i 다시 실행하면

real    0m16.701s
user    0m19.251s
sys     0m10.379s

npm ci 실행했을 때

real    0m20.997s
user    0m23.844s
sys     0m14.857s

단일 패키지를 제거하거나 호출하기 전에 전체 node_modules 폴더를 수동으로 삭제하려고 해도 이는 크게 다르지 않았습니다. npm ci 는 어쨌든 node_modules 의 내용을 삭제하는 것으로 시작하기 때문에 놀라운 일이 아닙니다.

실행할 때마다 diff -q -r node_modules_orig/ node_modules/ 를 실행하여 결과가 원래 종속성과 동일한지 확인했습니다. 항상 그랬다.

결론적으로 npm ci 를 사용하는 것은 node_modules 의 현재 상태에 관계없이 내 컴퓨터에서 ~21초가 걸리는 것 같습니다. 사용 npm i 최근에 복제 프로젝트 (NO node_modules ) 소요 ~ 18초 및 종속 변경된 프로젝트를 실행합니다 (현재 node_modules 필요한 종속성을 일치 ) ~3초가 걸립니다.

그렇다면 언제 npm ci 하는 것이 좋을까요? 더 빨라 보이지는 않지만(물론 이것은 단일 테스트일 뿐입니다) 최종 결과는 npm i 와 동일하므로 후속 빌드도 마찬가지로 안정적입니다.

npm ci 는 package-lock.json 에 있는 것 외에는 _정확히_ 필요한 경우에 선호됩니다. npm i 는 package-lock.json 있는 것을 정확히 설치한다고 보장하지 않습니다. 이것은 의도적으로 설계된 것입니다. package-lock.json 는 npm i 대한 입력이지만 출력이기도 합니다.

나는 npm i 가 다른 것을 설치(따라서 package-lock.json 수정)하는 몇 가지 경우만 남아 있다고 생각합니다. 예를 들어 일시 삭제된 패키지 버전일 수 있습니다.

npm ci 가 처음 소개되었을 때 npm i 는 package-lock.json 완전히 무시했거나 최소한 다른 버전을 설치하는 데 훨씬 더 적극적이었습니다.

어느 쪽이든, 그것은 정말로 중요하지 않습니다. npm ci 는 node_modules 폴더가 아직 존재하지 않을 때만 OK입니다. 그렇지 않으면 특히 Windows에서 엄청나게 느립니다. 따라서 npm i 는 package-lock.json 수정하지 않고 package-lock.json 내부에 있는 것을 정확히 설치하지 않을 _보장_ 플래그가 필요합니다.

이유와 방법을 더 이상 논의할 필요가 없습니다. 우리는 그것을 얻거나 얻지 못할 것입니다. 그대로, npm ci 짜증나.

/업데이트:
여기에 실행하는 환매 특약의 npm i 변경됩니다은 package-lock.json : https://github.com/fuzzykiller/npm-install-demo

변경 사항은 본질적으로 기술적일 뿐이지만 여전히 허용되지 않습니다.

빨리 반복하자면:

• npm ci 는 의도적으로 node_modules 의 콘텐츠를 항상 삭제합니다. 이는 느리기 때문에 비프로덕션 빌드에 바람직하지 않습니다. 그러나 package-lock.json 에 있는 정확한 버전의 패키지를 사용하므로 여러 상황에 적합합니다.

• npm install 는 node_modules 의 내용을 업데이트하므로 성능이 매우 우수하지만 package.json 버전 번호가 다른 경우 package-lock.json 의 내용을 무시합니다. 여러 상황에 바람직하지 않습니다.

• npm install --package-lock-only 는 문서에 설명되어 있습니다.

  --package-lock-only 인수는 node_modules를 확인하고 종속성을 다운로드하는 대신 package-lock.json만 업데이트합니다.

  이것은 위에서 설명한 시나리오에 유용하지 않은 것 같습니다.

지난 3년 동안 사람들이 요구한 것:

1. package.json 무시하고 package-lock.json 를 설치할 패키지의 최종 소스로 _only_ 존중하는 명령(어디서나).

2. node_modules 의 전체 내용을 삭제하지 않고 처음부터 모든 것을 다시 다운로드하지 않습니다.

문서와 로컬 테스트에서 모두 볼 수 있는 한 npm install 는 2 npm ci 충족하지만 1 npm ci 1 npm install --package-lock-only 충족하지 않습니다. 그 요구 사항의.

이 문제가 종료된 이유가 확실하지 않으며 원하는 동작을 얻을 수 있는 방법이 아직 없습니다.

편집: @fuzzykiller 의 예를 확장하려면 package-lock.json 업데이트되는 것이 아닙니다. 그것은 성가신 일이지만 내 빌드를 손상시키지 않을 것입니다. 그러나 package.json 에 퍼지 종속성이 나열되어 있고 해당 종속성의 bugfix 버전이 릴리스되면 새 컴퓨터에서 npm install 를 실행할 때 변경됩니다. 갑자기 두 기계 사이에 차이점을 설치했습니다. 우리 회사에서 정확히 이 동작으로 인해 버그가 발생했습니다. package-lock.json 를 Git에 다시 체크인해야 하는 것은 아닙니다.

이러한 상황에서는 npm ci 처럼 작동하는 명령을 사용하는 것이 바람직합니다. 이 명령은 package-lock.json 의 내용을 기반으로 _만_ 재생 가능한 설치를 만듭니다. 그러나 node_modules 폴더의 내용을 삭제하면 일부 환경과 상황에서는 빌드 속도가 너무 느려지지만 최종 프로덕션 빌드에는 적절한 동작입니다.

이 문제를 해결하기 위한 플래그가 어디에나 있을 수 있습니다. npm install --from-lockfile 수 있습니다. npm ci --preserve-existing 수 있습니다. 그러나 지금 우리는 npm install 플래그를 추가하도록 요청하는 사람은 누구나 해결책으로 npm ci 를 가리키고 플래그를 요청하는 사람은 누구나 원 안에 있는 것 같습니다. npm ci 는 솔루션으로 npm install 를 가리킵니다. 이 문제는 npm install --package-lock-only 가리키며 종료되었지만 해당 플래그는 사람들이 요구하는 것과 거의 반대입니다. package-lock.json 를 신뢰할 수 있는 소스로 간주하지 않으며 node_modules 폴더의 종속 항목도 업데이트하거나 설치하지 않습니다. :)

이 문제는 다시 열어야 합니다.