답변:
답은 Alberto Zaccagni가 제안한 것처럼 쉽지 않습니다. git repo에 node_modules를 포함하여 응용 프로그램 (특히 엔터프라이즈 응용 프로그램)을 개발하는 것이 가능한 선택이며 선택하는 대안은 프로젝트에 따라 다릅니다.
그는 node_modules에 대해 매우 잘 논쟁했기 때문에 나는 그것들에 대한 논쟁에 집중할 것입니다.
엔터프라이즈 앱을 완료했으며 3-5 년 동안 지원해야한다고 상상해보십시오. 내일 사라질 수 있고 더 이상 앱을 업데이트 할 수없는 npm 모듈에 의존하고 싶지 않습니다.
또는 인터넷에서 액세스 할 수없는 개인 모듈이 있으며 인터넷에서 앱을 빌드 할 수 없습니다. 또는 어떤 이유로 npm 서비스에 대한 최종 빌드에 의존하고 싶지 않을 수도 있습니다.
이 Addy Osmani 기사에서 장단점 을 찾을 수 있습니다 (Bower에 관한 것이지만 거의 동일한 상황입니다). 그리고 Bower 홈페이지와 Addy의 기사에서 인용하겠습니다.
"다른 사용자가 사용하도록 의도 된 패키지를 작성하지 않는 경우 (예 : 웹 앱을 작성하는 경우) 설치된 패키지를 항상 소스 제어로 확인해야합니다."
git checkout foo입니다. node_modules가 VCS에없는 경우 – 브랜치 전환은 git checkout foo ; npm install현재 NPM 버전이 작동하는 데 필요한 모든 것;)
모듈 세부 사항은에 저장됩니다 packages.json. 체크인 할 필요가 없습니다 node_modules.
사람들 node_modules은 모듈의 종속성을 잠그기 위해 버전 제어 에 저장 했지만 npm shrinkwrap 을 사용하면 더 이상 필요하지 않습니다.
@ChrisCM이 주석에 썼 듯이이 시점에 대한 또 다른 정당화 :
또한 기본 확장을 포함하는 모든 모듈은 아키텍처에서 아키텍처로 작동하지 않으므로 다시 빌드해야합니다. 리포지토리에 포함시키지 않는 구체적인 타당성을 제공합니다.
PhantomJS 및 node-sass와 같은 패키지 때문에 현재 시스템에 적절한 바이너리를 설치하기 때문에 node_modules를 체크인하지 않는 것이 좋습니다 .
즉, 한 Dev가 npm installLinux에서 실행 되고 node_modules를 체크인 하는 경우 Windows에서 저장소를 복제하는 다른 Dev에서는 작동하지 않습니다.
npm이 다운로드 한 tarball을 확인하여 다운로드 npm-shrinkwrap.json하는 것이 좋습니다. shrinkpack을 사용 하여이 프로세스를 자동화 할 수 있습니다 .
npm install --global shrinkpack축소 된 패키지를 설치할 다른 패키지를 요구함으로써 자체적으로 지연된 약점이 없습니까? 이것은 Addy의 조언에 위배됩니다.
shrinkpack빌드 종속성을 안정적으로 설치하려면 의존성이 필요합니다. 따라서 빌드 도구 자체의 설치는 모든 빌드 종속성을 버전 제어에 제출하는 것에 대한 논쟁의 약점이됩니다.
이 주제는 꽤 오래된 것입니다. 그러나 npm 에코 시스템의 상황이 변경되어 여기에 제공된 인수에 대한 업데이트가 누락되었습니다.
나는 항상 node_modules를 버전 관리하에 두지 말 것을 권합니다. 허용되는 답변과 관련하여 열거 된 거의 모든 혜택은 현재로서는 구식입니다.
게시 된 패키지는 더 이상 npm 레지스트리에서 취소 할 수 없습니다. 따라서 프로젝트가 이전에 의존했던 의존성을 잃어 버릴 염려가 없어도됩니다.
package-json.lock 파일을 VCS에 넣으면 자주 업데이트되는 종속성을 지원하여 동일한 package.json 파일에 의존하지만 설정이 다를 수 있습니다.
따라서 오프라인 빌드 도구가있는 경우 node_modules를 VCS에 배치하는 것이 유일하게 적합한 유스 케이스로 간주 될 수 있습니다. 그러나 node_modules는 일반적으로 매우 빠르게 커집니다. 모든 업데이트는 많은 파일을 변경합니다. 그리고 이것은 다른 방식으로 저장소에 영향을 미칩니다. 당신이 정말로 장기적인 영향을 고려한다면 그것은 장애가 될 수도 있습니다.
svn과 같은 중앙 집중식 VCS는 네트워크를 통해 커밋되고 체크 아웃 된 파일을 전송해야하므로 node_modules 폴더를 체크 아웃하거나 업데이트 할 때 지옥이 될 것입니다.
git과 관련 하여이 많은 추가 파일은 즉시 저장소를 오염시킵니다. git은 모든 파일 버전 간의 차이점을 추적하지 않지만 단일 문자가 변경되는 즉시 두 버전의 파일 사본을 저장합니다. 종속성에 대한 모든 업데이트는 또 다른 큰 변경 세트를 초래합니다. 백업 및 원격 동기화에 영향을 미치므로 git 저장소가 빠르게 커집니다. 나중에 git 저장소에서 node_modules를 제거하기로 결정한 경우 여전히 역사적인 이유로 그 일부입니다. git 저장소를 원격 서버 (예 : 백업)에 배포 한 경우 정리하는 것은 고통스럽고 오류가 발생하기 쉬운 다른 작업입니다.
따라서 효율적인 프로세스를 원하고 사소한 것을 "작게"유지하려면 Nexos Repository (또는 ZIP 아카이브가있는 일부 HTTP 서버)와 같은 별도의 아티팩트 저장소를 사용하여 이전에 가져온 종속성 세트를 다운로드에 제공하십시오.
node_modules 폴더를 확인 하는 것이 때로는 유용하다는 ivoszz에 동의 하지만 ...
시나리오 1 :
한 시나리오 : npm에서 제거 된 패키지를 사용합니다. node_modules 폴더에 모든 모듈이 있으면 문제가되지 않습니다. package.json에 패키지 이름 만 있으면 더 이상 얻을 수 없습니다. 패키지가 24 시간 미만인 경우 npm에서 쉽게 제거 할 수 있습니다. 24 시간이 지난 경우 연락해야합니다. 그러나:
지원 부서에 문의하면 해당 버전의 패키지를 제거하면 다른 설치가 중단되는지 확인합니다. 그렇다면 제거하지 않습니다.
따라서이 가능성은 낮지 만 시나리오 2가 있습니다 ...
시나리오 2 :
이 경우의 다른 시나리오 : 소프트웨어의 엔터프라이즈 버전 또는 매우 중요한 소프트웨어를 개발하고 package.json에 작성하십시오.
"dependencies": {
"studpid-package": "~1.0.1"
}function1(x)해당 패키지 의 방법 을 사용합니다 .
이제 studpid 패키지의 개발자는 방법 이름을 변경 function1(x)하는 방법에 대해 function2(x)그들은 그들은에서 자신의 패키지의 버전을 변경 ... 고장을 1.0.1에 1.1.0. npm install다음에 전화 할 때 1.1.0물결표 ( "studpid-package": "~1.0.1") 를 사용했기 때문에 버전을 수락 하기 때문에 문제가됩니다 .
전화 function1(x)하면 오류와 문제가 발생할 수 있습니다.
그러나:
전체 node_modules 폴더 (보통 100MB 이상)를 저장소로 푸시하면 메모리 공간이 필요합니다. 수백 MB (package.json & node_modules)에 비해 몇 kb (package.json 만 해당) ... 생각해보십시오.
당신은 그것에 대해 생각해야 / 그것을 할 수 있는 경우 :
소프트웨어는 매우 중요합니다.
문제가 발생하면 비용이 발생합니다.
npm 레지스트리를 신뢰하지 않습니다. npm은 중앙 집중식이며 이론적으로 종료 될 수 있습니다.
다음 과 같은 경우 99.9 %의 경우 node_modules 폴더를 게시 할 필요가 없습니다 .
자신만을위한 소프트웨어를 개발합니다.
무언가를 프로그래밍하고 다른 누군가가 관심을 가질 수 있기 때문에 GitHub에 결과를 게시하려고합니다.
node_modules를 저장소에 두지 않으려면 .gitignore파일을 만들고 행을 추가하십시오 node_modules.
npm install과 같습니다 . Windows 및 MacOS에서 호출 하면 일부 패키지에서 다른 파일 (OS 종속 파일)이 생성 될 수 있습니다. 그러나 나는 그것에 대해 확신하지 못한다. 누군가 이것이 사실인지 확인할 수 있습니까?
package-lock.json입니다. 나중에 studpid-package 업데이트에 문제가있는 경우 잠금 파일을 롤백하여 자신에게 맞는 정확한 버전을 찾을 수 있습니다.
한 가지 더 고려해야 할 : 체크인 node_modules만드는 것은 그것을 열심히 / 불가능의 차이를 사용 dependencies하고 devDependencies.
반면에 테스트를 거친 동일한 코드를 프로덕션에 푸시하는 것이 안전하다고 말할 수 devDependencies있습니다.