Yarn: `--pure-lockfile`을 `install`의 기본값으로 설정

나는 동의한다. yarn install 가 기본적으로 잠금 파일을 작성하는 이유에 대한 논의가 있어야 합니다. 전체 잠금 파일 개념과 모순되는 것처럼 보이기 때문입니다. 기본적으로 버전을 잠그지 않는 경우 잠금 파일이 있는 이유는 무엇입니까?

yarn install 가 존재하지 않는 경우 잠금 파일을 생성 하는 경우가 있습니다. 즉, 누군가 yarn 를 사용하도록 프로젝트를 변환하는 경우이지만 항상 작성하는 이유는 명확하지 않습니다. add/upgrade/remove 기본적으로 변경 작업만 잠금 파일을 업데이트해야 한다는 @bestander 의 의견에 동의합니다.

예를 들어 Yarn을 업그레이드하고 새 잠금 파일 버전을 사용하는 시나리오에서 add/remove/upgrade 없이 잠금 파일을 수정하는 방법이 있어야 합니까?

나는 옵션이 역전 될 수 있다고 생각합니다.

yarn install --save-lockfile

2016년 10월 17일 18:53에 James Ide [email protected] 은 다음과 같이 썼습니다.

추가/제거/업그레이드 없이 잠금 파일을 수정할 수 있는 방법이 있어야 합니다.
예: Yarn을 업그레이드하고 새 잠금 파일을 사용하는 시나리오에서
버전?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/yarnpkg/yarn/issues/570#issuecomment -254282256 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ACBdWJLpdvqiwcBwqE4KB3x3f4oCn_nVks5q07YYgaJpZM4KSlSw
.

저도 이게 헷갈립니다. 현재 기본 동작에 대한 이유는 무엇입니까?

Afaik, 기본 동작에 대한 강력한 이유는 없었습니다.
아이디어는 사람들의 잠금 파일을 "항상 녹색"으로 유지하는 것입니다.

BTW 홍보를 환영합니다

그 이유는 원사가 원래 install/add/upgrade 로 분할된 단일 install 명령으로 설계되었기 때문이라고 생각합니다.

그래서, 내가 이것을 올바르게 이해했는지 확인하기 위해 :

yarn 는 모든 종속성을 설치하고 잠금 파일도 수정합니다. CI 서버에서는 yarn install --pure-lockfile 를 사용해야 합니까?
설치 중에 잠금 파일이 수정되는 이유는 무엇입니까? 아무 것도 업그레이드하지 않기 때문에... Yarn은 잠금 파일에 설명된 대로 패키지를 설치하기만 하면 됩니다. 그렇죠?

설명 감사합니다!

문제는 기본적으로 잠금 파일이 순수하면 별도의 명령이 되므로 사람들이 업데이트하는 것을 잊어버릴 것입니다.

@kittens 잠금 파일은 패키지를 추가/제거/업그레이드할 때만 업데이트하면 안 됩니까? 잠금 파일과 초기 설치를 항상 업그레이드해야 합니다.

문제는 기본적으로 잠금 파일이 순수하면 별도의 명령이기 때문에 사람들이 업데이트하는 것을 잊어버릴 것입니다.

문제가 되는 것은 패키지 관리자의 주요 목표로 간주하는 항목에 따라 다릅니다.

제 생각에는 패키지 관리자가 수행하는 역할 중 하나는 프로젝트 개발을 가능한 한 쉽게 시작할 수 있도록 하는 것입니다. 간단한 yarn install 는 혼란 없이 개발을 시작하는 데 필요한 모든 패키지를 얻을 수 있습니다.

npm 를 사용하여 많은 개발자 인스턴스가 프로젝트에 참여했지만 프로젝트가 자신의 컴퓨터에서 작동하지 않는다는 것을 발견했습니다. 이러한 인스턴스는 일시적인 종속성으로 인해 버전이 주요 변경 사항이 있는 버전으로 충돌하거나 단순히 semver를 따르지 않기 때문에 발생했습니다. yarn 가 이러한 문제를 해결할 수 있기를 바랐지만 프로젝트의 모든 개발자가 yarn install --pure-lockfile 를 실행하여 프로젝트가 빌드될 것이라고 100% 확신해야 한다는 사실을 알면 그건 아닙니다. 경우.

패키지 관리자의 또 다른 역할은 프로젝트에 종속성에 대한 제어를 제공하는 것입니다. 기본적으로 순수하게 만들어진 경우 개발자는 yarn outdated 에서 오래된 버전을 확인한 다음 변경 사항을 검토하여 주요 변경 사항을 방지할 수 있습니다. 이렇게 하면 개발자가 실수로 잠금 파일을 커밋하는 것을 방지하기 위해 git commit -a 를 수행하는 것을 금지하는 대신 주어진 릴리스 기간에 버전을 범프할 수 있는 모든 권한을 개발자에게 제공할 수 있습니다.

나는 @esphen이 말하는 모든 것에 동의합니다. 나는 순수한 동작이 Yarn의 기본이 아니라는 사실에 놀랐습니다. 이러한 종류의 일관성이 Yarn이 NPM에 비해 갖는 주요 이점이라고 생각했습니다. 이것이 내가 보는 방식으로 NPM에서 전환해야 하는 가장 강력한 이유일 것입니다.

며칠 동안 yarn 를 사용하기 시작한 후 빌드를 깨고 완전히 놀랐습니다. 나는 솔직히 --pure-lockfile 가 많은 문서를 읽은 후 기본 동작이라고 생각했고, 어떻게 npm이 shrinkwrap을 사용하는 것보다 더 나은지에 대해 생각했습니다. 기본값으로 해주세요 :)

@ide 사람이 단지 NPM을 사용하여 업데이트 된 시나리오를 상상해 package.json 방법, yarn.lock 업데이트 될 것입니까?

누군가가 예기치 않게 수정되는 잠금 파일로 이어지는 시나리오를 작성해 주시겠습니까? 이러한 변화는 심각한 하나이며 작업이 등이되고, 업데이트 될 것을 기억하기에 많은 오버 헤드를 의미하는 명시하도록 업데이트를 요구하여 잠금 파일을 두 번째 클래스 시민을 수행

위의 추가 정보: 우리 빌드에는 하위 종속성으로 Github의 coffeescript가 있습니다. coffeescript는 일부 커밋을 푸시했고 빌드 프로세스에서 yarn install 만 실행하여 수정된 yarn.lock 를 얻었습니다.

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

누군가가 예기치 않게 수정되는 잠금 파일로 이어지는 시나리오를 작성해 주시겠습니까? 이 변경은 심각한 것이며 잠금 파일에 대한 업데이트를 명시적으로 요구함으로써 잠금 파일을 2급 시민으로 만듭니다.

나는 yarn install 를 node_modules를 빌드하는 명령으로 인식합니다.
package.json, yarn.lock 및 cleanup node_modules를 수정하는 yarn add 및 yarn remove 와 반대입니다.
add 및 remove 달리 저는 특히 부작용이 전혀 예상되지 않는 CI에서 install 100배 더 자주 실행합니다.

변화가 예상되지 않는 경우의 예:

1. 저는 Yarn 0.15.0을 사용하고 있고 팀원들은 Yarn 0.16.0을 사용 중입니다.
   0.16.0은 내 팀 동료가 생성한 yarn.lock에 대해 yarn install 를 실행할 때마다 yarn.lock의 항목 사이에 공백을 추가했기 때문에 커밋하지 않도록 기억해야 하는 수정된 yarn.lock 파일을 얻습니다.
   그 반대.
2. 내 다른 빌드 도구는 node_modules 상태의 "진실의 소스"로 yarn.lock에 의존합니다. 예기치 않게 변경되면 내 빌드에서 비결정성이 나타납니다.

@고양이

문제는 기본적으로 잠금 파일이 순수하면 별도의 명령이 되므로 사람들이 업데이트하는 것을 잊어버릴 것입니다.

누군가가 npm을 사용하고 package.json을 업데이트하는 시나리오를 상상해 보십시오. yarn.lock은 어떻게 업데이트됩니까?

yarn install 가 yarn.lock 업데이트하지 않아야 한다고 가정하면 yarn.lock 가 package.json 와 동기화되지 않은 경우에도 실패하여 yarn install --save-lockfile 모든 것을 다시 동기화하려면

+1 원사 설치는 yarn.lock을 변경해서는 안 됩니다.

1. 디버거는 oss 앱입니다. 우리는 기여자가 _good_ 버전을 설치하고 얻을 수 있기를 바랍니다. 우리는 사람들이 npm을 설치하고 전이 속성 때문에 중단되었다고 말했습니다. 실 설치를 사용하면 기여자가 실을 설치하고 실 잠금 변경으로 무엇을 해야 할지 모릅니다.

잠금 파일 업데이트에 대해 걱정하지 않습니다. 이상적으로 그린키퍼는 deps가 변경될 때 이 작업을 수행하고 잠금 파일 변경 사항을 병합할 수 있습니다.

이 문제에 대한 현재 생각을 업데이트하고 싶습니다. @kittens 와 저는 둘 다 --pure-lockfile 가 몇 가지 이유로 기본값이 _not_ 되어야 한다고 생각합니다.

사람들이 종속성을 추가/제거/업데이트하는 방법으로 시작합니다. 이에 대한 명령이 있지만 손으로 ​​또는 Lerna 와 같은 다른 도구를 사용하여 package.json 를 수동으로 업데이트하는 것이 일반적입니다.

Yarn과 npm 모두에서 package.json 수동으로 수정하면 다른 설치를 실행할 때 package.json _syncs_할 것으로 예상됩니다. 그런 의미에서 yarn install 는 거의 yarn sync 로 이름이 바뀔 수 있습니다.

동기화 주제에 대해 새 종속성을 사용하여 설치를 실행할 때 node_modules 디렉토리에 이러한 변경 사항이 반영될 것으로 예상합니다. yarn.lock 는 node_modules 의 조수 역할을 하므로 동일한 방식으로 동기화를 유지해야 합니다.

귀하의 package.json 는 진정한 정보의 궁극적인 소스입니다. 즉, yarn에 대한 인터페이스이며, 구성이며 항상 관심을 가져야 하는 유일한 것입니다. 이상적인 세계에서는 단순히 yarn.lock 를 커밋하고 다시는 그것에 대해 생각할 필요가 없습니다.

참고로 저는 이 문제에 대해 지지를 표명하는 많은 사람들이 여기서 실제로 논의되고 있는 내용에 대해 혼란스러워하고 있다고 생각합니다.

기본적으로 --pure-lockfile 를 사용한다고 해서 Yarn이 일관되고 신뢰할 수 있는 결과를 생성하지 않는다는 의미는 아닙니다. 동일한 package.json 는 동일한 yarn.lock 되어 100% 동일한 node_modules 가 됩니다.

package.json 를 업데이트하면 yarn.lock 파일이 업데이트되고 node_modules 업데이트됩니다. 그것은 사물에 대한 매우 자연스러운 질서이며 우리는 그렇게 유지해야 합니다

package.json 업데이트했지만 yarn install 를 실행하여 누군가가 가져올 것이라고 확신하는 모든 것을 동기화하지 않았을 때 CI가 다른 종속성을 얻을 수 있다는 것과 관련하여 문제)-- 나와 다른 사람들은 Yarn 통합에 대해 다양한 CI 도구에 대해 이야기해 왔으며 사람들이 큰 문제로 볼 경우 기본적으로 --pure-lockfile 를 사용하도록 쉽게 푸시할 수 있습니다.

이 변경을 수행하면 종속성을 변경할 때 훨씬 더 자주 부정적인 영향을 미칠 것입니다. 내가 나열한 이유로 나는 우리가 이 문제를 닫아야 한다고 말합니다.

@jameskyle 뭔가를 명확히 할 수 있다면 감사하겠습니다.

1. 개발자는이 package.json 종속성이 포함 된 "foo": "^1.0.0"
2. 개발자는 yarn install 합니다. foo 패키지는 현재 버전 1.0.0 이므로 [email protected] 잠기는 yarn.lock 파일을 만듭니다.
3. 개발자는 Git에 yarn.lock 를 추가합니다.
4. 개발자는 리포지토리의 로컬 복사본에서 단위 테스트를 실행하고 모든 것이 잘 작동합니다.
5. 개발자는 리포지토리를 CI(예: Travis)에 푸시합니다.
6. CI는 yarn install 를 실행하지만 foo 는 이제 1.1.0 버전으로 업데이트되었으므로 Yarn은 [email protected] 하고 yarn.lock 를 새 버전으로 덮어씁니다. foo
7. foo 버전 1.1.0 에서 주요 변경 사항이 있으므로 CI가 중단됩니다.

비슷한 상황은 다음과 같습니다.

1. 개발자는 "foo": "^1.0.0" 종속성을 포함하는 package.json 가지고 있으며 [email protected] 로 잠겨 있고 yarn.lock 는 Git에 저장되어 있습니다.
2. 단위 테스트는 리포지토리의 개발자 로컬 복사본에서 제대로 작동합니다.
3. 기여자는 수정 + 풀 요청을 할 의도로 리포지토리를 복제합니다.
4. 기고자가 yarn install 를 실행하면 yarn.lock 가 업데이트되는 [email protected] 버전이 생성됩니다.
5. foo 버전 1.1.0 에서 주요 변경 사항이 있었기 때문에 이제 기고자의 빌드가 손상되었습니다.

대부분의 사람들이 걱정하는 상황이 바로 그런 상황인 것 같아요.

따라서 yarn install 의 현재 동작에 위의 문제가 없음 을 명확히 할 수 있다면 대부분의 두려움이 제거될 것이라고 생각합니다. :+1:

이러한 상황 중 어느 것도 적용되지 않습니다. 종속성이 업데이트되었다고 해서 package.json 변경한 경우에만 해당 종속성을 얻을 수 있다는 의미는 아닙니다.

내가 말했듯이 이것은 실제 시나리오가 아닌 사람들이 가지고 있는 유일한 관심사인 것처럼 보이기 때문에 이 문제를 닫을 것입니다. 이 문제는 더 많은 혼란을 야기할 수 있습니다.

그러나 위에서 보고한 것처럼 github에서 종속성을 설치하는 경우 잘못된 동작이 있습니다.

@adamchainz 따로 수정해야 하므로 커밋에 쉽게 잠글 수 있습니다.

이러한 상황 중 어느 것도 적용되지 않습니다. 종속성이 업데이트되었다고 해서 package.json 변경한 경우에만 해당 종속성을 얻을 수 있다는 의미는 아닙니다.

@jameskyle : 이것이 실제 시나리오가 아닌 이유를 잘 모르겠습니다. 자세히 설명해 주시겠습니까?

입력이 package.json 이고 출력이 yarn.lock 메모 작성 기능을 상상해보십시오.

1. 처음에는 패스 package.json 그것이 생성 yarn.lock 하고 결과를 캐시합니다.
2. 다음에 _that same_ package.json 를 실행할 때 결과는 캐시되기 때문에 정확히 동일합니다.
3. package.json 를 변경하면 캐시가 무효화되었으며 이제 yarn.lock 가 다시 계산됩니다.

지금 우리가 이야기하는 것은 # 3을 없애고 대신 yarn.lock 를 변경된 package.json 의해 무효화되지 않은 것처럼 취급하는 것입니다. 메모이즈 기능이 있으면 정말 이상할 것이고 Yarn에도 정말 이상한 행동이 될 것입니다.

커밋 및 새 버전 측면에서 패키지에 어떤 일이 발생하는지 _should_는 관련이 없습니다(git 커밋에 버그가 있는 경우 별도로 수정해야 하지만 이 문제와 관련이 없습니다).

내가 만든 것보다 더 복잡하지만(각 패키지 버전은 개별적으로 효과적으로 "기억"되고, 한 패키지의 버전을 변경해도 나머지는 무효화되지 않음) 이제 모든 사람이 요점을 알 수 있기를 바랍니다.

@thejameskyle : 명확함(그리고 호기심)을 위해 yarn.lock 파일이 있는 프로젝트가 있고 누군가가 저장소를 풀다운한다고 가정해 보겠습니다. yarn install 또는 npm install 실행하지 않고 이 사람은 package.json 파일에 새 종속성을 추가한 다음 yarn install 합니다. 이 경우 기존 yarn.lock 파일이 완전히 무시됩니까?

여기에서 내가 풀고자 하는 다양한 일들이 일어나고 있습니다(말장난 의도 없음).

첫째, 사람들은 논쟁의 여지가 없다고 생각하는 여러 가지 요구 사항을 제기했습니다(그리고 이로 인해 기존 동작의 일부가 버그가 되며, 이에 대해서는 곧 다루게 될 것입니다).

원래 버그 보고서에서.

환경(현재 설치된 원사의 버전)에 따라 lockfile을 수정하면 일관성이 상실됩니다.
예상되는 동작은 무엇입니까?
원사 설치 시 yarn.lock 또는 package.json을 작성하지 마십시오.
yarn.lock을 업데이트하려면 yarn upgrade를 사용하십시오.

더 정확하게 말하면 예상되는 의미론은 다음과 같습니다.

• package.json 이 yarn.lock 가 마지막으로 변경된 이후로 변경되지 않은 경우 yarn.lock 는 진실의 소스이므로 업데이트해서는 안 됩니다.
• 경우 package.json 지난 이후에 변경된 yarn.lock 변경 업데이트 yarn.lock 만족 너무 package.json 및 갱신 node_modules .
• yarn update 가 실행되면 모든 종속성을 다시 해결하고 package.json 를 충족하는 모든 항목의 최신 버전을 가져옵니다.

이것은 저장소가 머신 에서 yarn.lock 가 체크인된 경우, yarn은 항상 이를 소스로 취급해야 하며 yarn.lock 대한 업데이트를 생성하지 않고 점프해야 합니다. 가져오기 단계로 직접 이동합니다.

이것이 현재 yarn의 동작이 아닌 한 버그가 될 것이라고 생각합니다.

@esphen 은 다음

나는 동의한다. 전체 잠금 파일 개념과 상반되는 것처럼 보이기 때문에 처음에 yarn install이 기본적으로 잠금 파일을 작성하는 이유에 대한 논의가 있어야 합니다. 기본적으로 버전을 잠그지 않는 경우 잠금 파일이 있는 이유는 무엇입니까?

이것이 말하려는 것은 기존의 잠금 파일이 여전히 최신 상태라면 원사가 새 잠금 파일을 작성해서는 안 된다는 것입니다. 나는 그것에 동의합니다.

나는 변경 작업만 기본적으로 잠금 파일을 업데이트해야 한다는 @bestander 의 의견에 동의합니다(예: 추가/업그레이드/제거).

여기서 중요한 문제는 package.json 대한 변경으로 인해 yarn.lock 가 업데이트되어야 하는지 여부입니다. 제 생각에는 package.json 대한 변경 사항이 yarn.lock 의해 만족되지 않으면 yarn.lock 업데이트 해야 합니다 .

원사와 같은 잠금 파일 시스템의 중요한 불변성은 일반적인 워크플로를 사용하여 개발자가 앱을 실행할 때 실제로 사용되는 패키지가 package.json 지정된 버전과 일치하는지 확인할 package.json 가 yarn.lock 와 동기화되지 않는 것이 허용되면 이것은 사실이 아니며 사람 독자가 yarn.lock 를 주의 깊게 읽어야 한다는 것을 알 수 있는 유일한 방법입니다.

대부분의 사용자가 잠금 파일에 대해 생각하는 가장 좋은 방법은 현재 package.json 사용된 모든 패키지의 정확한 버전을 나타내는 실행 실의 아티팩트라는 것입니다. 체크인하면 다른 공동 작업자, CI 및 프로덕션 코드에서 동일한 버전을 사용할 수 있습니다.

@Guuz 는 다음과

그래서, 내가 이것을 올바르게 이해했는지 확인하기 위해 :
yarn은 모든 종속성을 설치하고 잠금 파일도 수정합니다. CI 서버에서는 yarn install --pure-lockfile?을 사용해야 합니다.

이 질문은 이 스레드에서 몇몇 사람들이 한 감정을 반영합니다.

Cargo에는 " package.json 가 yarn.lock 의해 만족되지 않으면 하드 오류입니다"라는 --locked 플래그가 있습니다. Bundler에는 유사한 플래그( --frozen )가 있습니다. 이는 Heroku가 Bundler를 채택할 때 추가되어 Gemfile 를 로컬로 변경하고 Gemfile.lock 를 확인하는 것을 잊었을 때 사람들에게 심각한 오류를 제공합니다.

아이디어는 정상적인 개발 중에 package.json 변경할 수 있고 원사에서 yarn.lock 가 동기화 상태를 유지하도록 하려는 것입니다(다시, 지정된 버전이 package.json 항상 실제로 사용되는 것과 일치합니다.

그러나 배포할 때 package.json 변경하고 로컬 yarn 명령을 실행했으며 yarn.lock 체크인을 잊어버렸기 때문에 분기된 것은 거의 항상 오류입니다 yarn . 이것은 package.json 버전이 애플리케이션이 실행될 때 사용된 실제 버전과 일치하지 않는다는 것을 의미합니다. 이는 우리가 말했던 원사의 기본 불변성을 위반한다고 말했습니다.

@esphen 은 다음과

제 생각에는 패키지 관리자가 수행하는 역할 중 하나는 프로젝트 개발을 가능한 한 쉽게 시작할 수 있도록 하는 것입니다. 간단한 원사 설치로 혼란 없이 개발을 시작하는 데 필요한 모든 패키지를 얻을 수 있습니다.

나는 이것이 논쟁의 여지가 없다고 생각한다.

npm을 사용하여 많은 개발자 인스턴스가 프로젝트에 참여했지만 프로젝트가 자신의 컴퓨터에서 작동하지 않는다는 것을 발견했습니다. 이러한 인스턴스는 일시적인 종속성으로 인해 버전이 주요 변경 사항이 있는 버전으로 충돌하거나 단순히 semver를 따르지 않기 때문에 발생했습니다. 저는 yarn이 이러한 문제를 해결할 수 있기를 바랐지만 프로젝트의 모든 개발자가 yarn install --pure-lockfile 을 실행하여 프로젝트가 빌드될 것이라고 100% 확신해야 한다면 그것은 사실이 아닙니다.

yarn install --pure-lockfile 실행하면 잠금 파일 내부의 버전이 package.json 지정된 버전과 충돌하더라도 잠금 파일이 존중됩니다. 개발자 잊어들이 체크인 경우에만 첫 번째 장소에서 발생한다 yarn.lock 받는 사람 변경 한 후 package.json .

패키지 관리자의 또 다른 역할은 프로젝트에 종속성에 대한 제어를 제공하는 것입니다. 기본적으로 순수하게 만들어지면 개발자는 오래된 버전을 확인하기 위해 원사를 살펴본 다음 변경 사항을 검토하여 주요 변경 사항을 피할 수 있습니다. 이렇게 하면 우발적인 잠금 파일 커밋을 방지하기 위해 개발자가 git commit -a를 수행하는 것을 금지하는 대신 지정된 릴리스 기간에 버전을 범프할 수 있는 모든 권한이 개발자에게 제공됩니다.

package.json 가 변경되지 않았다면 제 생각에는 yarn.lock 가 업데이트되면 버그입니다. 버그의 적어도 하나의 경우가 원래 보고서에 있는 것 같습니다.

lockfile은 환경(현재 설치된 yarn의 버전)에 따라 수정됩니다.

이것은 오류이며 수정되어야 한다고 생각합니다.

나중에 스레드에서 @thejameskyle 은 다음과

입력이 package.json이고 출력이 yarn.lock인 메모이즈 함수를 상상해 보세요.

그건 내보기에, 정확히 올바른 정신 모델이다 ( " yarn.lock 와 경우에만 경우 변경할 수 있습니다 package.json 변경"), 그리고 추상화 누수 경우 우리가 그것을 수정해야합니다.

@adamchainz 는 다음과

위의 추가 정보: 우리 빌드에는 하위 종속성으로 Github의 coffeescript가 있습니다. coffeescript는 일부 커밋을 푸시했고 우리는 단지 yarn install을 실행하여 빌드 프로세스에서 수정된 yarn.lock을 얻었습니다.

그리고 나중에:

그러나 위에서 보고한 것처럼 github에서 종속성을 설치하는 경우 잘못된 동작이 있습니다.

여기서 문제는 yarn이 git sha를 잠긴 버전의 git 종속성의 일부로 취급하지 않는다는 것입니다. Cargo와 Bundler는 모두 잠금 파일로 직렬화되는 "정확한" 버전의 개념을 가지고 있습니다. git 소스의 경우 "정확한" 버전은 SHA입니다. 당신이 새로운 클론을 할 때 그런 다음, 단지 package.json 및 yarn.lock 실행 yarn , 당신이 필요로 정확하게 코드를 얻을하는 데 필요한 모든 정보가 있습니다.

원본 git 코드를 검토할 때 이 상호 작용을 놓쳤다는 것을 고백해야 합니다. 코드에 일부 SHA 추적이 있지만 yarn install 는 수화 종속성 그래프가 이를 준수하는지 확인하지 않습니다.

TL;DR

나는 yarn.lock 가 package.json 자동으로 동기화되어야 한다는 @thejameskyle 및 @kittens의 의견에 동의합니다. 왜냐하면 저는 사용자가 package.json 지정된 버전을 가정할 수 있어야 한다고 생각하기 때문입니다. 앱이 실행될 때 무엇을 사용하는지 정렬하십시오.

그러나 package.json 가 변경되지 않은 경우에도 yarn.lock 에서 부적절한 이탈을 일으키는 몇 가지 버그가 있는 것으로 보입니다.

• 여러 시스템에서 원사 버전을 변경하면 잠금 파일이 업데이트됩니다.
• package.json 가 업데이트되지 않은 경우에도 git 종속성이 업데이트되어 잠금 파일이 업데이트됩니다.

또한 Cargo의 --locked 플래그와 같은 것을 고려해야 합니다. 이 플래그는 개발자가 package.json 업데이트하고 업데이트된 yarn.lock 을 확인하는 것을 잊어버린 경우 CI에서 빌드를 빠르게 실패하는 데 사용할 수 있습니다

@jameskyle 감사합니다! :heart: package.json 변경 후 yarn.lock 을 업데이트해야 한다는 귀하와 @kittens의 의견에 동의합니다.

@wycats 평소와 같이 매우 철저하고 통찰력 있는 게시물입니다. :+1: 나는 당신의 의견에 동의하고 --locked 플래그(또는 이와 유사한 것)에 대한 아이디어도 좋아합니다. 우리는 그것에 대해 새로운 문제를 만들어야 합니다.

git SHA 문제를 추적하기 위해 #1568을 만들었습니다.

@wycats , 매우 통찰력 있는 개요를 풀어주셔서 감사합니다!

이는 저장소가 머신에서 처음 복제될 때 yarn.lock이 체크인된 경우, yarn은 항상 이를 원본으로 취급하고, yarn.lock에 대한 업데이트를 생성하지 않고, 가져오기 단계로 직접 이동해야 함을 의미합니다.
이것이 현재 yarn의 동작이 아닌 한 버그가 될 것이라고 생각합니다.

이것이 바로 이 문제가 공개된 시나리오입니다.
회사에는 몇 가지 활성 버전의 Yarn이 있으며 우리 규모로는 모든 곳에서 원자적 업데이트를 수행할 수 없을 것이라고 생각합니다.
yarn 0.13, 0.14 및 0.15를 기반으로 빌드하면 package.json이 동기화된 경우에도 yarn.lock 파일에 약간의 변형이 도입되었습니다.
이로 인해 몇 가지 문제가 발생했습니다. 예를 들어 소스 트리의 변경으로 인해 캐시가 무효화되어 Buck 빌드 속도가 느려졌습니다.
이로 인해 나와 두 팀이 몇 시간 동안 작업했습니다.

@jameskyle , 의견을 공유해 주셔서 감사합니다.
저는 package.json이 yarn.lock과 동기화되지 않는 시나리오를 공정하다고 생각하지 않았습니다. 그리고 당신은 유효한 포인트가 있습니다.

그러나 @wycats가 지적했듯이 원래 버그 보고서는 유효합니다.
이 문제를 수정하는 것은 유효한 빌드를 갖는 데 중요하며 모든 이해 관계자를 만족시키는 솔루션을 제시하기 위해 문제를 다시 열겠습니다.

@wycats

더 정확하게 말하면 예상되는 의미론은 다음과 같습니다.

• package.json 이 yarn.lock 가 마지막으로 변경된 이후로 변경되지 않은 경우 yarn.lock 는 진실의 소스이므로 업데이트해서는 안 됩니다.
• 경우 package.json 지난 이후에 변경된 yarn.lock 변경 업데이트 yarn.lock 만족 너무 package.json 및 갱신 node_modules .
• yarn update 가 실행되면 모든 종속성을 다시 해결하고 package.json 를 충족하는 모든 항목의 최신 버전을 가져옵니다.

이것은 저장소가 머신 에서 yarn.lock 가 체크인된 경우, yarn은 항상 이를 소스로 취급해야 하며 yarn.lock 대한 업데이트를 생성하지 않고 점프해야 합니다. 가져오기 단계로 직접 이동합니다.

이것들은 내가 #364에서 추가한 의미론입니다.

@bestander 이러한 휴리스틱을 하셨습니다 . 어떤 추가 변경을 제안하고 있습니까?

이 문제는 매우 광범위하며 우리는 이미 --pure-lockfile 가 기본값이 아니라는 데 동의했으며 @wycats가 설명한 경험적 방법을 따를 것입니다. 이 문제가 계속 열려 있으면 제목에 이 동작과 관련된 현재 문제가 반영되어야 합니다.

@kittens 가 좋은 것 같습니다. 문제를 업데이트하겠습니다.
또는 package.json이 변경되지 않았을 때 잠금 파일을 변경하는 설치와 관련된 새 항목을 열어야 할 수도 있습니다.

새 문제로 이동할 수 있습니까? 여기에 있는 이 댓글은 아카이브로 보관할 수 있습니다.

@thejameskyle , 오늘 새 문제를 만들고 여기에 링크하겠습니다.

새로운 초점을 맞춘 문제 생성 https://github.com/yarnpkg/yarn/issues/1576

package.json의 패키지가 yarn.lock에 없으면 yarn install 실패하도록 하는 옵션이 있으면 흥미로울 것입니다. 패키지가 잠겨 있지 않으면 실패

위의 내용을 읽은 후에도 여전히 모호한 설명을 추가합니다.

tldr; package.json 관련 없는 변경은 패키지를 변경되지 않은 package.json semver와 호환되는 최신 버전으로 업데이트하지 않습니다.

위의 문구 중 일부를 기반으로 yarn.lock 가 package.json 해시에 캐싱된 것처럼 들렸 으므로 yarn.lock 가 (업데이트됨/캐시 무효화됨) )에 변경에 package.json 관련이없는 변경 이후에 문제가 될 것이다 (즉,에 갱신 "description" 또는 다른 종속)이 종속의가 발생할 수 있습니다 yarn.lock 버전으로 업데이트하기 동일한 기존 package.json semver 내의 최신 버전.

그러나 패키지의 yarn.lock 항목은 해당 package.json semver가 업데이트될 때만 기록되는 것을 확인했습니다(새 semver가 기존 yarn.lock 버전과 호환되더라도 결과적으로 버전 업데이트가 필요하지 않음).

예를 들어,

• yarn add lodash@^4.17.1 설치 [email protected]
• 나중에 [email protected] 를 사용할 수 있습니다.
• 원사는 계속 [email protected] 를 설치합니다.
• lodash의 버전이 package.json 로 변경 될 때까지 (또는 yarn add/upgrade/remove가 lodash에 대해 특별히 실행됨).

빵 부스러기 #1576

BTW와 같은 작은 기사로 문서에 기꺼이 기여할 수 있다면 커뮤니티에 좋을 것입니다.
핵심 팀은 모두 문제를 수정하고 새로운 기능을 추가하느라 바쁘고 커뮤니티가 문서를 유지하는 데 도움이 된다면 감사할 것입니다.

@CrabDude 설명을 공유해 주셔서 감사합니다.

위의 예에서 lodash 및 자체 종속성만 yarn.lock 에서 잠금 버전이 업데이트된다는 것을 의미합니까? 예를 들어 다른 종속성 이 새 잠금 버전을 가질

또는 두 번째 예: yarn.lock 가 심하게 구식이고 사용자가 yarn add 를 실행하여 package.json에 새 종속성을 추가한다고 가정해 보겠습니다. 다른 모든 오래된 패키지는 이제 yarn.lock 에서 업데이트됩니까, 아니면 그대로 유지됩니까?

@라킨스

위의 예에서 lodash와 자체 종속성만 yarn.lock에서 잠금 버전이 업데이트된다는 것을 의미합니까?

예. 이것은 내 예에서 지지되는 것 같습니다.

다른 모든 오래된 패키지가 이제 yarn.lock에서 업데이트됩니까, 아니면 그대로 유지됩니까?

lodash 가 아닌 종속성 트리/패키지의 잠금 항목이 업데이트되지 않는 것 같습니다. lodash 의 하위 종속성만 있을 것입니다.

제 관점에서 이들 각각은 바람직하고 기대되는 것입니다.

머리말 : 나는 실을 좋아한다. 그러나 그것은 나를 끝없이 좌절시킵니다.

우리 회사에서 yarn install 는 package.json 변경하지 않음에도 불구하고 서로 다른 시스템(각각 동일한 버전을 실행함) 간에 잠금 파일을 지속적으로 변경합니다. 그리고 업데이트할 때 yarn add 사용하여 업데이트합니다. 이것은 CI가 빌드 후 git 상태가 깨끗한지 확인하여 잠금 파일 체크인과 같은 작업을 잊지 않았는지 확인하고 자주 변경되기 때문에 성가신 일입니다.

원사에 대한 나의 기대는 _기본적으로_ 모든 시스템에서 동일한 node_modules를 보장하는 것이었습니다. 추가 플래그가 없습니다. 그것은 편리함보다 정확성을 우선시할 것입니다. 불확실성을 원하면 npm을 직접 사용할 수 있습니다. 파일이 변경되면 무언가 변경되었다는 신호이므로 자세히 조사해야 합니다. 변경되어서는 안됩니다.

질문

• lockfile이 변경되더라도 node_modules의 내용은 생성될 때와 항상 동일하다는 말입니까? 나는 이것이 사실이라고 믿지 않지만 만약 그렇다면 이 스레드의 혼란을 이해합니다. 그것은 실이 그렇지 않은 것처럼 보이지만 실이 옳은 일을 한다는 것을 의미할 것입니다.
• package.json 변경되면 잠금 파일이 재생성됩니다. 특정 프로그래머의 node_modules 상태에 따라 의도치 않게 많은 종속성을 변경할 수 없었습니까? Yarn은 델타를 결정하고 기존 잠금을 ​​가능한 한 최대한 보존해야 합니다(아직 그렇지 않은 경우).
• 이유는 무엇입니까 yarn add 의 버전 지정 package.json A를 ^ ? 다시 말하지만, 저는 yarn의 약속이 의존성을 동결한다는 것을 이해했습니다.

관련 버그

• node_modules 에서 임의의 패키지를 삭제하면 yarn install 다시 설치하지 않고 성공을 나타냅니다. 그것들이 많이 사라지면 다시 설치합니다. npm 는 이와 관련하여 좀 더 철저합니다.
• node_modules를 삭제하고 새로 설치하면 잠금 파일이 다시 생성되는 경향이 있습니다(말 그대로 예상하는 것과 반대입니다. 잠금 파일에 있는 것을 정확히 설치하고 다른 작업은 수행하지 않을 것으로 예상합니다)
• 새로 설치한 후 패키지 또는 node_modules 를 건드리지 않고 잠금 파일을 삭제하면 yarn이 이를 다시 생성하며 일반적으로 이전 버전과 매우 다릅니다. 이것은 아무것도 변경하지 않고 실행할 때마다 다른 코드를 생성하는 컴파일러와 같습니다.

전반적으로, yarn은 설치를 더 빠르게 하지만 핵심 (in)능력에서 실패한 것으로 보입니다. 기본적으로 버전을 일관되게 고정합니다. 나는 내 프로젝트를 시작하는 데 도움이 되는 편의가 필요하지 않습니다. 나는 수년에 걸쳐 거대한 팀을 통해 그것을 유지하는 데 도움이 필요합니다. 프로그래머는 똑똑하고 의도적이어서 변경을 원할 때 명시적으로 요청할 것입니다.

끊임없이 변화하는 잠금 파일은 자신감을 심어주지 못하고 끊임없는 번거로움을 줍니다. 나는 package.json이 lockfile과 일치하지 않는다는 것, lockfile이 node_modules와 일치하지 않는다는 것, 잠긴 버전이 더 이상 존재하지 않는다는 등의 경고와 오류를 선호합니다. 내 의존성에 대해 의도적인 결정을 내립니다.

@jspiro ,
여기서 몇 가지 문제가 제기됩니다.
각 문제를 별도로 여는 것이 좋습니다. 그렇지 않으면 주석에서 손실됩니다.

최신 버전의 Yarn을 사용 중이신가요?
0.18-0.19에서 우리는 머신 사이에서 yarn.lock 파일에 대한 수정을 볼 수 없습니다.

질문:

lockfile이 변경되더라도 node_modules의 내용은 생성될 때와 항상 동일하다는 말입니까? 나는 이것이 사실이라고 믿지 않지만 만약 그렇다면 이 스레드의 혼란을 이해합니다. 그것은 실이 그렇지 않은 것처럼 보이지만 실이 옳은 일을 한다는 것을 의미할 것입니다.

동일한 잠금 파일에 대해 Dev 및 선택적 종속성을 생략할 수 있습니다.
그러나 플랫폼별 패키지를 제외하고 bing 설치되는 것은 node_modules의 동일한 위치에 동일한 패키지가 있어야 합니다.

package.json이 변경되면 잠금 파일이 다시 생성됩니다. 특정 프로그래머의 node_modules 상태에 따라 의도치 않게 많은 종속성을 변경할 수 없었습니까? Yarn은 델타를 결정하고 기존 잠금을 ​​가능한 한 최대한 보존해야 합니다(아직 그렇지 않은 경우).

좋은 기능 요청입니다. 이에 대한 PR을 보고 싶습니다.

원사 추가가 ^로 package.json의 버전을 지정하는 이유는 무엇입니까? 다시 말하지만, 저는 yarn의 약속이 의존성을 동결한다는 것을 이해했습니다.

이는 npm의 행동을 반영합니다.
정확한 버전에 대해 yarn add [email protected] 또는 yarn add is-array --exact 를 수행할 수 있습니다.
언젠가는 정확한 버전을 기본값으로 설정해야 할 수도 있습니다. 이것은 RFC에서 논의될 수 있습니다.

node_modules에서 임의의 패키지가 삭제되면 다시 설치하지 않고 yarn install에 성공이라고 표시됩니다. 그것들이 많이 사라지면 다시 설치합니다. npm은 이와 관련하여 좀 더 철저합니다.

Yarn은 기본적으로 빠른 얕은 검사를 실행합니다.
심층 검사를 수행하면 속도가 느려지지만 작업 중이므로 빠르게 심층 검사를 수행할 수 있는 방법이 있습니다.
하지만 node_modules의 파일을 만지면 안 됩니다. 수정을 위해 각 파일을 확인하면 설치 환경이 매우 느려집니다.
얕은 검사를 건너뛰려면 설치하기 전에 node_modules/.yarn-integrity 파일을 제거하십시오. 이것은 공식적이지 않으며 변경될 수 있습니다.
공식적인 방법은 yarn install --force 를 실행하는 것입니다. 전체 설치를 강제 실행하지만 부작용으로 yarn.lock을 다시 작성합니다.

node_modules를 삭제하고 새로 설치하면 잠금 파일이 다시 생성되는 경향이 있습니다(말 그대로 예상하는 것과 반대입니다. 잠금 파일에 있는 것을 정확히 설치하고 다른 작업은 수행하지 않을 것으로 예상합니다)

한동안 이것을 보지 못했습니다.
문제를 열고 이것이 재현될 수 있으면 참조하십시오.

새로 설치한 후 package 또는 node_modules를 건드리지 않고 lockfile을 삭제하면 yarn이 이를 재생성하며 일반적으로 이전 버전과 매우 다릅니다. 이것은 아무것도 변경하지 않고 실행할 때마다 다른 코드를 생성하는 컴파일러와 같습니다.

얼마 후 새로운 버전의 전이적 종속성이 릴리스되었을 수 있습니다.
그 때문에 호이스팅 로직 때문에 node_modules의 구조가 크게 바뀔 수 있습니다.
설계된 대로 작동합니다.
https://github.com/yarnpkg/yarn/pull/2580에 import 명령이 있습니다.
그러면 기존 node_modules에서 잠금 파일을 생성할 수 있습니다.

@jspiro , Yarn은 젊은 커뮤니티 주도 프로젝트입니다. 더 나은 작업을 위한 PR을 환영합니다.

최소한 원하는 기본 동작을 설정하는 옵션을 얻을 기회가 있습니까?

현재 https://github.com/yarnpkg/yarn/issues/3490 이 문제를 수정하고 yarn install 인해 예상하지 못한 동작으로 잠금 파일이 최적화될 수 있으며 이를 수정하겠습니다.
이것이 이 변경을 요청하는 이유일 수 있습니다. 그렇지 않으면 수동으로 package.json을 변경하는 경우에만 yarn.lock 파일이 변경되어야 합니다.

.yarnrc에서 --pure-lockfile/--frozen-lockfile을 true로 설정할 수 있으며 기본적으로 설치 명령에 추가됩니다.

--install.pure-lockfile true

내 문제는 순수 잠금 파일을 사용하지 않으면 잘못된 버전의 종속성이 설치된다는 것입니다. 원치 않는 yarn.lock 변경 사항과 관련이 없습니다.

재현 단계와 관련된 문제를 제출할 수 있습니까?
우리가 그것을 정리할 것입니다

나는 잘 때와 같이이 물린했다 package.json 및 yarn.lock 으로 인해 개발자가 실수를 통해 종속성을 추가하는 동기에서 나왔을 npm install --save 대신 yarn add .

pure-lockfile 가 기본값이어야 하고 오히려 frozen-lockfile 가 yarn install 의 기본값이어야 한다는 점에 동의하지 않습니다.

frozen-lockfile 는 yarn.lock 와 package.json 가 동기화되지 않은 경우 오류 메시지를 생성합니다. 따라서 frozen-lockfile 는 빌드 머신(예: 젠킨스)에서 예상대로 빌드를 실패로 표시하므로 매우 유용합니다.

그런 다음 package.json / yarn.lock에 추가할 버전을 결정하는 것은 개발자의 몫입니다.

yarn install 의 불행한 기본값은 아직 종속성에 잠겨 있지 않은 최신 버전을 가져오고 프로젝트의 일부가 되지 않을 업데이트된 버전 yarn.lock 을 작성합니다. 따라서 예기치 않은 버전 충돌로 인해 빌드가 중단될 수 있습니다. 그것이 바로 잠금 파일이 있는 이유입니다.

요지는 다음과 같아야 합니다.

만 같은 명령 add , remove 및 upgrade 변이한다 yarn.lock .

install 는 그렇게 해야 합니다. 즉, 잠긴 버전에 종속성을 설치하거나 package.json 와 yarn.lock 사이의 불일치를 감지하면 실패합니다. (애초에 yarn.lock 이 없는 경우는 예외입니다. 그런 다음에만 생성할 수 있지만 다시는 건드리지 않아야 합니다.)

따라서 frozen-lockfile은 빌드 머신(예: 젠킨스)에서 빌드가 실패하므로 매우 유용합니다.

CI 모드에 있음을 감지하면 자동으로 활성화할 수 있습니까?

@BYK 여기에 추가하기 전에 이 문제가 종료

새로 오픈한다고 합니다☺️

저는 yarn.lock이 package.json과 자동으로 동기화되어야 한다는 @thejameskyle 및 @kittens에 동의합니다.

이것이 말했는지 확실하지 않지만 다음 경우를 대비하여: package.json의 내용이 변경될 때 전체 yarn.lock을 무효화할 필요가 없습니다. package.json 내에서 수정된 패키지의 종속성만 무효화할 수 있습니다. TypeScript만 업데이트한 경우 Fe는 TypeScript의 종속성을 수정해야 합니다(다른 변경되지 않은 패키지에 대한 고려 포함).