Yarn: .gitignore에 yarn.lock을 넣어야 하나요?

git에 yarn.lock을 추가 해야 합니다. 무시하지 마세요.

https://yarnpkg.com/en/docs/migrating-from-npm을 참조

yarn 또는 yarn add <package> 하면 Yarn은 패키지의 루트 디렉터리에 yarn.lock 파일을 생성합니다. 이 파일을 읽거나 이해할 필요가 없습니다 . npm 대신 Yarn을 사용하기 시작하면 yarn.lock 파일은 사용자가 가지고 있는 것과 정확히 동일한 종속성을 갖도록 합니다.

명확히 하자면, 이것은 애플리케이션뿐만 아니라 라이브러리에도 적용됩니다. npm-shrinkwrap.json 와 반대로 최상위 프로젝트의 yarn.lock 사용되기 때문입니다. 그렇죠? 따라서 yarn.lock 파일과의 종속성은 불필요한 중복을 생성하지 않습니다. 복잡한 개발 종속성이 있고 라이브러리의 모든 기여자가 동일한 빌드 및 테스트 구성을 갖기를 원하는 경우 라이브러리에 유용합니다.

이 올바른지?

@고닝
리포지토리에 yarn.lock 파일을 저장하는 것이 항상 최선의 아이디어는 아닐 수도 있습니다.
예를 들어 저는 시노피아를 사용하고 있습니다. 따라서 사용자 지정 npm 레지스트리가 있습니다. 나는 주로 개인 모듈이 있는 다른 프로젝트에 이 레지스트리를 사용합니다.
그러나 공개 종속성만 있는 git 리포지토리에 공개 프로젝트를 푸시하면 yarn.lock에 종속성에 대한 잘못된 링크가 있고 내 CI 시스템이 프로젝트를 빌드하지 못합니다.
종속성은 내 로컬 저장소를 가리킵니다.
이것은 다른 개발자가 내 저장소를 복제하는 경우에도 발생할 수 있습니다.
yarn.lock 파일을 gitignore에 넣는 것 외에는 이 문제를 해결할 수 있는 방법이 있습니까?

또한 npm 레지스트리를 미리 인증한 경우(예: myget이 npm에 프록시인 경우) yarn.lock 에는 패키지에 대한 사전 인증 링크가 포함되며 이는 주요 보안 위반입니다 🎉
이것은 큰 글꼴로 어딘가에 문서화되어야 합니다.

@Pfeifenjoy npm 대신 git submodule을 사용하여 개인 패키지에 연결하면 어떻게 될까요?
git을 사용하면 배포 키(ssh를 통해)를 사용하여 저장소에 액세스할 수 있습니다.

@beenotung 저는 git을 종속성 관리자로 사용하는 것을

또한 내가 참조하는 종속성은 내 로컬 sinopia 계정에 저장되기 때문에 (내 자신의 프로젝트뿐만 아니라) 모두 다른 주소를 얻습니다. 내 프로젝트가 git에서 의존하는 모든 노드 모듈을 참조
또한 yarn.lock 파일을 제거하는 것이 더 쉽습니다.

@Pfeifenjoy 원사가 수행하려는 작업에 충돌이 있습니까? 다른 설치에 종속성이 있는지 확인하는 방법을 제공하려면 포함시키십시오. 의도한 대로 수행됩니다. 개인 저장소와 소스를 가져오는 경우 저장소의 키나 솔트를 특히 무시하는 것과 같은 방식으로 코드를 말마다 공유하는 방법에 대해 매우 신중해야 합니다. 프로젝트 readme에 대한 경고, 기능/풀 요청을 만들 것입니다).

인증된 소스에 대한 액세스가 잠금 파일에 포함되어 있음을 사용자에게 경고하는 실행 시 yarn은 경고를 제공해야 하지만 다시 말하지만 이는 기능 요청이 될 것입니다.

@thisolivier는 합리적으로 들립니다.

그냥 메모.
https://github.com/yarnpkg/yarn/issues/3330 때문에 중국 또는 기타 제한 지역에 거주하고 다른 레지스트리(eq taobao)로 모듈을 빌드하는 경우 yarn.lock 를 추가해야 합니다. .gitignore하고 package-lock = false 를 .npmrc에 씁니다.

여기에서 내가 내 yarn.lock을 커밋하지 않는 이유: 일부 모듈에는 기본 종속성이 있으며 일부 플랫폼에서만 작동합니다( 원사.lock 이 생성되는 플랫폼과 정확히 유사한 플랫폼).
사용자를 만족시키고 버그 없는 설치를 유지하기 위해 원사를 제거합니다. 원사가 이를 해결하는 방법에 대한 명확한 문서가 포함된 솔루션을 제공하지 않는 한 동의할 것입니다.
(항상 개발자의 실화를 듣습니다)

또한 커밋을 정말 추하게 만듭니다.

나는 여기에서 가장 많이 찬성된 의견에 동의하지 않습니다.

프로젝트가 사용하는 NPM 경우 • 커밋 package-lock.json 의 repo와 gitignore yarn.lock
이 프로젝트는 원사를 사용하는 경우 • 커밋 yarn.lock 의 repo와 gitignore package-lock.json

즉, 항상 yarn.lock 을 repo 에 커밋해서는 안 _안_ 하고 OP의 질문에 대답 하려면 .gitignore 에 추가할 수 있습니다.

다른 사람들이 npm 대신 Yarn을 사용하기 시작할 때, yarn.lock 파일은 그들이 당신이 가지고 있는 것과 정확히 동일한 종속성을 갖도록 보장합니다.

우선, 공개 npm 레지스트리만 사용하는 경우에만 그렇지 않습니다. 더 나쁜 것은 Yarn에서 개인 조직에 인증되지 않고(여전히 npm에 있더라도) 공개 레지스트리에 동일한 이름의 패키지가 존재하는 경우 프롬프트 없이 잘못된 패키지를 설치할 것입니다. 원사가 오류 없이 설치되는 이유는 혼란스러울 수 있지만 앱은 원사를 사용할 때는 작동하지 않지만 npm을 사용할 때는 작동합니다.

둘째, 많은 코드베이스는 원사를 _사용하지 않습니다_. "언제 원사로 전환하는지"의 문제가 아닙니다. 거의 모든 노드 서비스 및 기본 웹 서버는 얀으로 이동할 계획 없이 npm을 사용합니다. 나는 React와 함께 yarn을 좋아합니다. 그게 전부입니다.

위에서 언급한 @Pfeifenjoy :

사용자 지정 npm 레지스트리가 있습니다. 개인 모듈이 있는 다른 프로젝트에 주로 이 레지스트리를 사용합니다.

그러나 공개 종속성만 있는 git 리포지토리에 공개 프로젝트를 푸시하면 yarn.lock에 종속성에 대한 잘못된 링크가 있고 내 CI 시스템이 프로젝트를 빌드하지 못합니다.

^ 또 다른 문제는 로컬에서 해결하더라도 솔루션을 yaml 또는 CI에 대한 구성 및 앱을 실행하는 다른 모든 위치에 통합해야 합니다. 어떤 레지스트리와 명령을 사용해야 하는지 알 수 있는 일종의 논리입니다. 짜증나고 불필요한 소리

또 다른 사항 - 모든 사람이 항상 yarn.lock 를 repo에 커밋하고 절대 무시하지 않도록 권장하면 개발자는 이미 npm에 크게 의존하는 repo에서 yarn을 사용하기 시작할 것입니다. 잘 작동하는 경우에도 2개의 잠금 파일에 중복이 있을 것이며 이는 종속성 지옥의 문을 열 것입니다. 그리고 어떤 개발자는 기여 그래프를 엉망으로 만드는 ~25k 라인 yarn.lock 을 커밋한다는 것을 알고 있습니다.