나는 이것이 버그라고 생각하지 않습니다. 문제를 재현 할 수 있었지만 차이점은

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

이 변경은 잠금 파일의 최적화 일 뿐이며 의미 체계를 변경하지 않습니다. yarn install 실행할 때 잠금 파일을 업데이트해야 할 때 경고를 추가 할 계획이지만 잠금 파일이 동일하고 정확한지 확인하려면 --frozen-lockfile 옵션을 사용해야합니다.

나는 이것이 약간 직관적이지 않다는 것을 인정해야하며 우리는 이에 대한 좋은 해결책을 찾으려고 노력하고 있습니다. # 4147에 대한 토론을 따르거나 토론에 기여할 수 있습니다.

이것이 버그가 아니며 # 4147이 토론을 계속하기에 좋은 장소라는 데 동의한다면, 문제를 종결 해 주시기 바랍니다. :)

@BYK 귀하의 사려 깊은 답변에 감사드립니다. # 4147을 읽은 후 저는이 문제를 해결하는 것에 대해 울타리에 섰습니다. 여기에 좀 더 많은 토론이 도움이되기를 바랍니다.

4147은 yarn.lock 및 package.json이 동기화되지 않은 경우에만 해당되는 것 같습니다. 실제로 유일한 시간 최적화가 언급 된 내용은 https://github.com/yarnpkg/yarn/issues/4147입니다. #issuecomment -321894341 - 그리고 문제에 대한 그 주석 접촉이 우려 나 다음 수정 원사 yarn.lock 변경이 이루어지지 된 파일 package.json .

yarn.lock 파일은 내 종속성이 어떻게 든 변경되는 경우에만 변경되어야하는 것 같습니다. 사실,이 시점까지, 나는 그들이 변화 보면 나의 DEVS를 말하고 한 yarn.lock 파일을, 그것의 시간은 실행 yarn install . 최근 업그레이드를 통해 내 변경 사항을 수신하고 yarn install 를 실행 한 후 잠금 파일이 변경 (최적화)되었다고보고 한 여러 사람이 있습니다. 이로 인해 혼란스러운 상황이 발생합니다. 변경 사항을 적용해야합니까? 어떻게 든 잠금 파일을 사전 최적화해야합니까 (가능합니까?)?

단기적으로는 모든 리포지토리에서 --frozen-lockfile true 를 .yarnrc 에 추가해야 할 것 같습니다.하지만이 솔루션은 다음에 언급 된 워크 플로를 배제하기 때문에이 솔루션의 열렬한 팬이 아닙니다. # 4147 여기서 package.json 를 편집 한 다음 yarn install 를 실행합니다.

얀의 호출이 yarn.lock 수정하려는 의도입니까?

@BYK 당신이 매우 바쁘다는 것을 알고 있기 때문에 이것에 대해 귀찮게해서 미안하지만 이것에 대한 확실한 답을 얻고 싶습니다. 내 팀에 종속성 변경 사항을 배포하기위한 워크 플로는 다음과 같이 발전했습니다.

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

이것은 잠금 파일을 올바르게 업데이트하고 (# 4476 참조), 팀 동료가 잠금 파일 변경 사항을 체크인하지 않도록 잠금 파일을 최적화하는 것 같습니다.

우리 팀이 원사를 잘못 사용하고 있습니까? install 명령마다 잠금 파일이 변경 될 것으로 예상해야합니까?

@artlogic IMHO, 팀 동료는 단지 최적화 일지라도 잠금 파일 변경 사항을 체크인 할 수 있어야합니다. yarn install 잠금 파일을 최적화하는 것은 직관적이지 않지만 팀의 각 개발자가 안전하게 수행 할 수있는 작업이라는 개념에 동의합니다. 왜 그걸 금지하고 싶은지 이해가 안 돼요.

즉, 잠긴 버전을 거의 포기하므로 ​​워크 플로가 예기치 않은 부작용을 초래할 수 있습니다. 잠금 파일을 삭제하면 yarn이 모든 종속성 버전을 다시 확인해야하며 package.json 에서 지적한대로 최신 버전을 가져 오려고 시도하여 잠재적 인 손상, 특히. 둘 이상의 종속성이 향후 버전에서 동시에 중단되는 경우.

여전히 설치가 잠금 파일을 건드리지 않도록 강제하려면 frozen-lockfile 플래그를 사용해야합니다.

 yarn add {blah}

잠금 파일을 확인하면 다른 개발자가 다음을 사용합니다.

   yarn install --frozen-lockfile

--frozen-lockfile 를 true 에 .yarnrc true 에 추가하지 마십시오. 업데이트 할 수 없으므로 다음을 참조하십시오. # 4570

종속성을 업그레이드하려면 다음을 실행하십시오.

 yarn upgrade

하나의 종속성 만 업그레이드하려는 경우 :

  yarn upgrade {blah}

한 종속성의 특정 버전 만 설치할 수도 있습니다.

  yarn install {blah}@1.5

이를 통해 장기적으로 더 미세 조정하고 두통을 줄일 수 있습니다.

@ k0pernikus- 자세한 답변에 감사드립니다. 먼저 두 가지 문제를 합친 것에 대해 사과해야합니다. # 4476이 내 작업 흐름의 일부를 주도하고 있습니다. yarn upgrade 가 다소 깨진 것처럼 보인다는 사실은 물론이 문제와는 아무런 관련이 없습니다.

워크 플로에 관해서는 한 개발자가 새로운 종속성을 유지 / 테스트하고 다른 개발자가 코드 기반에서 작업하는 유일한 팀이라고는 상상할 수 없습니다. 내가 시작한 일에서 가장 큰 문제는 새로운 종속성을 설치 / 테스트하고 모든 사람에게 yarn install 를 실행하도록 지시 한 다음 변경된 yarn.lock 를 커밋해야하는지에 대해 4-5 개의 질문을받는 것입니다. . "잠금 파일이 변경되면 커밋"이라고 말하면 더 나쁜 위치에있는 것 같습니다. 그 시점에서 다음과 같은 커밋 잠금으로 끝날 수 있기 때문입니다.

• yarn.lock 변경 (dev4)
• yarn.lock 변경됨 (dev3)
• yarn.lock 변경됨 (dev2)
• yarn.lock 변경 (dev1)
• 업데이트 된 종속성 (나)

그러나 이것은 yarn이 작동하도록 의도 된 방식 일 수 있습니다. 따라서 우리 팀의 프로젝트에서는 add 및 upgrade 발생하도록 모든 리포지토리를 고정 잠금 파일을 사용하도록 변경합니다. 변경할 잠금 파일.

하나의 추가 시나리오 ... 이것은 잠재적으로 복제 및 설치할 때마다 잠금 파일이 변경 될 수 있기 때문에 많은 기여자가있는 프로젝트에 잠재적 인 성가신 일이 될 수 있습니다. 풀 요청에서 이러한 최적화를 원하지는 않습니다. 대부분의 FOSS 프로젝트가 실을 사용하여 고정 된 잠금 파일로 전환하려는 의도입니까?

@artlogic 우리 팀은 정확히 이런 이유로 프로젝트의 .yarnrc 에 --install.pure-lockfile true 를 가지고 있습니다.

@jboler- 전에는 그 설정을 본 적이 없었습니다. 한 번 살펴 봐야 할 것 같지만, 우리의 모든 리포지토리와 내가 가지고있는 모든 FOSS 프로젝트의 모든 리포지토리에 대해 .yarnrc 에 추가 할 것을 제안 할 것 같습니다.

원사 팀의 누군가가 yarn install 의 의도가 모든 실행에서 잠금 파일을 변경할 수 있고 변경할 것이라는 것을 확인할 수 있다면 (종속성에 대한 변경이 없음에도 불구하고)이 문제를 종료하겠습니다.

@artlogic 늦게 응답 해

문제는 yarn install 가 잠금 파일을 잠재적으로 변경하는 것이 __expected__입니다. 나는 이것이 이상적이지 않고 더 나은 의사 소통이 필요하다는 것을 알고 있습니다. 나는 정말로 더 나은 기본값을 원하지만 그 동안 @jboler 와 같은 --frozen-lockfile 대신 사용하는 것이 최선의 해결책이 될 것이라고 생각합니다. 사람들이 yarn add 등을 사용하는 대신 단순히 package.json 를 편집하여 종속성을 업데이트하는 것을 선호하는 워크 플로

@BYK 나는 @artlogic에 동의했다. 이 동작은 매우 혼란 스럽습니다.

내가 시작한 일과 관련된 큰 문제는 새로운 종속성을 설치 / 테스트하고 모든 사람에게 yarn install을 실행하도록 지시 한 다음 변경된 yarn.lock이 커밋되어야하는지에 대해 4-5 개의 질문을받는 것입니다.

우리 팀은 매일 yarn install 를 실행하는 ~ 50 명의 사람들로 구성되어 있습니다 :(

@vkrol Yarn이 동작을 변경할 때까지 문제를 피하기 위해 --install.frozen-lockfile true 또는 --install.pure-lockfile true 가있는 .yarnrc 파일을 체크인 할 수 있어야합니다. 도움이 될까요?

@BYK pure-lockfile 는 도움이되지만 frozen-lockfile 는 도움이되지 않습니다. 내가 올바르게 이해하면 frozen-lockfile이 활성화되어 있으면 yarn install 오류와 함께 실패합니다. 이 행동은 우리의 경우 절대 용납 할 수 없습니다.

@vkrol 내 기본 설정은 frozen-lockfile 입니다. 잠금 파일을 변경해야하고 일관성이없는 경우에만 실패하기 때문입니다. pure-lockfile 하면 잠금 파일이 거의 쓸모 없거나 매우 부정확 할 수 있지만 여전히 실패하지는 않습니다. Yarn은 단순히 행복하게 계산 한 내부 해상도를 사용합니다. 모든 팀원이 똑같은 버전의 Yarn을 사용한다면 괜찮을 것입니다. 그렇지 않으면 위험 할 수 있습니다.

@BYK 아마도 frozen-lockfile 동작을 올바르게 이해하지 못할 수도 있습니다. 잠금 파일이 package.json 내용과 일치하지만 내부 최적화가 필요한 경우 실패합니까?

@vkrol 파일을 더 최적화 할 수있을 때 실패해서는 https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK 나는 그것에 대해 몰랐다. 이 옵션을 시도해 보겠습니다. 감사합니다! 나는이 사실이 어딘가에 문서화되어야한다고 생각한다.

@BYK

파일을 더 최적화 할 수 있지만 package.json과 일관성이 있고 자체적으로 일관성이있을 때 실패해서는 안됩니다.

이 플래그 사용의 단점을 발견했습니다. yarn.lock이이 명령의 반복 된 호출보다 최적화 될 수있는 경우 yarn install --frozen-lockfile 은이 플래그없이 "integrity"검사를 통해 최적화되지 않습니다. 이것은 버그입니까? 별도의 발행물을 만들어야합니까?

@BYK 귀하의 답변에 감사드립니다. 우리 팀의 프로젝트를 위해 우리는 이제 frozen-lockfile 하고 있으며 (상대적으로) 잘 작동합니다. 그러나이 문제는 나에게 다소 우려되는 부분으로 남아 있습니다. 특히 불필요한 최적화 yarn은 yarn install 실행할 때 잠금 파일을 만듭니다.

다음은이 동작으로 인해 문제가 발생하는 부분에 대한 가장 명확한 예입니다.

1. yarn add [blah] 사용하여 새 종속성을 추가하고 업데이트 된 package.json 및 yarn.lock 커밋합니다.
2. 내 패키지의 기여자는 변경 사항을 풀다운하고 yarn.lock 이 업데이트되었음을 ​​확인하고 yarn install 를 실행합니다.
3. 경우에 따라 이러한 기여자는 설치 후 수정 된 yarn.lock 끝납니다. 이 경우 어떻게해야합니까? 누가 먼저 풀 리퀘스트를 제출할 수 있는지 보는 경쟁입니까?

명확하게 말하면 package.json 가 수정 된 경우 yarn install 수정에 문제가 없습니다. yarn.lock . 내 문제는 package.json 가 변경되지 않은 경우 최적화입니다. 세 가지 가능한 해결책이 있습니다.

1. 종속성을 중앙에서 관리하는 모든 프로젝트에 --install.frozen-lockfile true 를 .yarnrc 파일에 추가하도록 지시합니다. 이것은 아마도 많은 프로젝트가 될 것입니다-대부분의 NPM 패키지는 추측합니다.
2. 추가 단계 (예 : yarn add --optimize [blah] 중에 yarn이 잠금 파일을 최적화하도록하는 스위치를 제공하십시오. 그런 다음 패키지 관리자에게 항상 해당 스위치를 사용하도록 지시하십시오.
3. package.json 가 업데이트 된 것으로 나타나지 않는 한 설치 단계 동안 yarn이 yarn.lock 를 최적화하지 못하도록합니다.

나는 옵션 3을 옹호하고 있지만 옵션 2도 합리적인 선택이라고 볼 수 있습니다.

시간 내 줘서 고마워!

yarn install 가 yarn.lock 파일을 업데이트하지 않고 대신 "Yarn.lock 파일이 오래되었습니다. yarn blah 를 실행하여 지금 업데이트하십시오.

@BYK 왜 ~ ~ 원사에 최적화 yarn.lock 에를 yarn install 가 아닌 경우 add / upgrade 실행됩니다?

편집 : 오타 수정

@ spencer-brown : 내가 본 것을 기반으로 실제로 설치에 최적화를 적용합니다.

yarn.lock에 대한 최적화는 yarn add에서 실행되어야하지 않습니까? yarn.lock은 어쨌든 변경됩니다. 이것은 @artlogic 의 최근 댓글에서 두 번째 옵션입니다. 그러면 최적화가 발생하지 않는 이유는 다른 사람이 다른 yarn.lock 변경을 수행 할 필요가 없습니다.

@artlogic oops, typo :)-내 의견은 "does"라고 말해야합니다. 편집.

우리는 작곡가를 많이 사용하고 composer install 는 잠금 파일을 건드리지 않습니다.

잠금 파일을 변경하거나 최적화하려면 composer update 또는 composer require ( yarn add 와 동일)을 실행해야합니다.

수년 동안 우리는 composer install 의 모호한 동작에 대해 걱정할 필요가 없었습니다.

나는 yarn이 약간 다른 역할을 수행한다는 것을 알고 있지만 composer는 composer.json 에 수동 업데이트가 이루어지고 잠금 파일과 동기화되지 않는 것과 동일한 문제가 있습니다. 현재 composer install 는 composer.json 파일을 완전히 무시하고 경고를 발행합니다.

우리는 작곡가를 많이 사용하고 composer install 는 잠금 파일을 건드리지 않습니다.

잠금 파일을 변경하거나 최적화하려면 composer update 또는 composer require ( yarn add 와 동일)을 실행해야합니다.

수년 동안 우리는 composer install 의 모호한 동작에 대해 걱정할 필요가 없었습니다.

나는 yarn이 약간 다른 역할을 수행한다는 것을 알고 있지만 composer는 composer.json 에 수동 업데이트가 이루어지고 잠금 파일과 동기화되지 않는 것과 동일한 문제가 있습니다. 현재 composer install 는 composer.json 파일을 완전히 무시하고 경고를 발행합니다.

안녕하세요, 잠금 파일은 후속 설치에서 변경되지 않아야합니다. 그냥 멍청 해요. 최적화가 가치가 있다고 생각되면 버전 관리에 포함되지 않는 별도의 파일을 만드십시오.

Bundler의 Gemfile.lock과 마찬가지로 yarn.lock의 요점은 yarn 설치가 실행될 때마다 모든 환경에서 결정적 결과를 보장 할 수 있다는 것입니다. 원사 설치가 잠금 파일을 변경하면 보증을 잃게됩니다. yarn add 또는 yarn update와 같은 다른 명령은 분명히 yarn.lock을 변경해야하지만 yarn install은 변경하지 않아야합니다. 우리 팀은 우리가 원하지 않는 환경에 약간 다른 패키지 버전이 설치되어있는 문제에 부딪 혔습니다.

yarn install --pure-lockfile 이 기본값이어야하며 현재 동작을 얻기 위해 --fix-my-dev-process-inconsistencies-for-me-magically 옵션이있을 수 있다고 생각합니다.

@ryancastle --pure-lockfile 는 잠금 파일에 대한 업데이트가 있다는 것을 알려주지 않습니다. 하나만 생성하지 않습니다. 이로 인해 여전히 예기치 않은 동작이 발생할 수 있습니다. 업데이트가 필요한 경우 --frozen-lockfile 가 실패합니다.

나는 잠시 동안 .yarnrc 에서 --install.frozen-lockfile true 을 (를) 사용하고 있으며 제대로 작동하는 것 같습니다. 트릭은 해당 플래그가 적용되지 않은 저장소에 대한 초기 yarn.lock 를 만드는 것입니다. 생성 된 후에는 설치시 yarn.lock 변경할 수 없지만 업데이트는 변경할 수 있습니다. 이 워크 플로를 사용하기 시작하면 yarn.lock 대한 실수로 변경 한 횟수가 0으로 감소했습니다.

@artlogic 사이드 노트 : .yarnrc 에도 frozen-lockfile true 이 (가) 있었는데 , 이제는 yarn.lock 대한 의도적 인 변경 문제가 발생했기 때문에 빌드 서버에서만 적용합니다 package.json 수동으로 편집했거나 npm을 사용하여 종속성을 추가했기 때문에 package.json 를 yarn.lock 에 동기화하려고 할 때 yarn.lock 가 생성되지 않았습니다.

참조 : https://github.com/yarnpkg/yarn/issues/4570

@ k0pernikus '사용 사례는 우리가하지 않았 왜 --frozen-lockfile 와 기본 yarn install . 나는 솔직히 package.json 를 편집 한 다음 yarn install 를 실행하여 잠금 파일을 업데이트하는 사람들을 방해하지 않으면 좋은 타협이 무엇인지 알 수 없습니다. 나는 깃발이나 yarn sync 와 같은 새로운 명령을 제안했지만 아이디어를 구체화 한 다음 구현하기 전에 커뮤니티에서 판단해야합니다.

또한 이것은 주요 변경 사항이므로 Yarn 2.x가 필요합니다. :)

yarn sync와 같은 플래그 또는 새로운 명령

나에게 좋은 소리 👍. yarn install "package.json 및 yarn.lock이 동기화되지 않았습니다. 잠금 파일을 업데이트하려면 'yarn sync'를 실행하십시오."라는 알림이 표시 될 수 있습니다.

솔직히 package.json을 편집하고 yarn install을 실행하여 lockfile을 업데이트하는 사람들을 방해하지 않고서는 좋은 타협이 무엇인지 알지 못합니다.

특정 시점에서 적절한 작업 흐름이 무엇인지 결정해야한다고 생각합니다. 나에게 이것을 활성화하는 것은 거의 반 패턴을 장려하는 것처럼 보입니다.

나는 깃발이나 yarn sync와 같은 새로운 명령을 제안했지만 아이디어를 구체화하고 구현하기 전에 커뮤니티에서 판단해야합니다.

나에게 이것은 합리적인 타협처럼 보입니다. package.json 를 직접 편집해야한다고 주장한다면, 명령을 실행하여 동기화 상태로 되 돌리는 것이 좋습니다.

내가보고 싶은 것은 다음과 같습니다.

• yarn install 없이 yarn.lock 는 yarn.lock 만듭니다.
• yarn install 와 yarn.lock 는 수정하지 않습니다. yarn.lock 와 package.json 사이에 불일치가있는 경우 오류가 반환됩니다 ( @indeyets 가 표시됨).
• yarn sync (또는 yarn install -s )는 yarn.lock 다시 package.json 와 동기화합니다.

package.json 가 잠금 파일과 동기화되지 않은 경우에도 yarn install 가 yarn.lock 수정한다는 근본적인 우려가 있습니다. 위에서 몇 가지 "최적화"를 수행하는 것을 볼 수 있습니다. 최소한의 변경없이이 동작을 비활성화 할 수 있습니까?

package.json이 잠금 파일과 동기화되지 않은 경우에도 yarn install이 yarn.lock을 수정한다는 근본적인 우려가 있습니다. 위에서 몇 가지 "최적화"를 수행하는 것을 볼 수 있습니다. 최소한의 변경없이이 동작을 비활성화 할 수 있습니까?

여기에도 같은 감정이 있습니다. 나는 이것이이 문제가 열려있는 구체적인 이유라고 생각했습니다. "동기화"는 # 4147에서 논의되고 있습니다.

이것이 제가 처음에이 문제를 검색 한 이유입니다.

이것과 # 4147을 합칠까요?

@BYK 여기서 논의 된 거의 모든 내용이 # 4147과 병합 될 수 있다고 생각합니다. 내가 전에 말했듯이, 나는 아직도 저를 염려하는 유일한 방법은 "최적화"생각이 yarn install 에 수행 yarn.lock 에 대한 변경이 수행되지 않은 경우에도 장소 package.json .

내 생각은 yarn 2.0으로가는 길에 임시 방편으로 이러한 최적화를 비활성화해야한다는 것입니다. 이것이 획기적인 변화라고 생각하지 않습니다.

@artlogic에 100 % 동의합니다.

CircleCI를 설정했는데 빌드가 계속 실패하고 yarn.lock 캐싱 문제까지 추적했습니다. Rails에서 왔기 때문에 설치 명령으로 잠금 파일이 잠길 것으로 예상합니다.

이것은 CircleCI에서 캐시 검사를 위해 제안 된 것입니다 : https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

yarn.lock은 변경되지 않아야 할 때 변경 될 수 있으므로 작동하지 않습니다.

참고로 macOS 10.13.6의 yarn 1.10.1에서 OP의 버그 자극을 시도했지만 yarn.lock이 변경되지 않았 음을 발견했습니다. 즉, 내가 시도했을 때 :

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

따라서 원사 1.10.1을 사용할 때 yarn install 는 원사 1.0.1을 사용할 때 OP에서와 같이 yarn.lock 변경되지 않았습니다. (나는 이것이 OP라고 생각하는 것처럼 좋은 것이라고 생각합니다.)

@dtgriscom Cordova에서 더 이상 문제가 발생하지 않는다는 것이 좋습니다! 완전히 고쳐 졌는지 아니면 yarn이 여전히 설치시 잠금 파일을 최적화하려고할지 궁금합니다.

알아두면 좋겠죠? 문제가 패키지에 따라 다르다는 점을 확인했습니다. 버전별로 다를 수도 있습니다. ( "우리는 변경하지 말아야 할 것을 변경하고 싶다"는 정당화를 들어 본 적이 없습니다. "최적화 중입니다"외에는 ...)

install 작업이 기본적으로 결정적이어야한다는 데 전적으로 동의합니다. .lock 파일을 업데이트하려면 개발자가 파일을 변경하는 것으로 알고있는 작업을 수행해야합니다. 예를 들어, 패키지의 현재 상태를 손상시키지 않는 소규모 최적화를 허용하는 yarn install --optimize 와 같은 것을 실행할 수 있습니다.

내 권한없이 잠금 파일이 손상되지 않았 음을 확신 할 수 있도록 문서를 찾아야하는 별도의 옵션을 추가하는 것은 특히 실패를 일으킬 수있는 경우 매우 혼란 스럽습니다. 개발자로서 저는 제가 사용하는 도구를 제어 할 수 있기를 기대하며이 동작이 저를 빼앗아가는 것 같습니다.

잠금 파일을 수정하지 않고 종속성 설치시에만 작동하도록 기본 동작을 뒤집는 것을 다시 고려하십시오. package.json 가 잠금 파일과 동기화되지 않았다는 경고와 함께 무결성 검사가 실제로 필요한 모든 것입니다.

나는 사람들에게 잠금 파일에 대한 변경 사항을 포함한 PR은 새롭거나 종속성을 업데이트 할 때만 잠금 파일이 변경되기 때문에 병합되지 않을 것이라고 말하고 있습니다. 다음은 설치 문서에 나와있는 내용입니다.

yarn install

package.json 내에 나열된 모든 종속성을 로컬 node_modules 폴더에 설치합니다.

yarn.lock 파일은 다음과 같이 사용됩니다.

• yarn.lock 이 있고 package.json 나열된 모든 종속성을 충족하기에 충분하면 yarn.lock 기록 된 정확한 버전이 설치 되고 yarn.lock 는 변경되지 않습니다. . Yarn은 최신 버전을 확인하지 않습니다.
• yarn.lock 가 없거나 package.json 나열된 모든 종속성을 충족하기에 충분하지 않은 경우 (예 : package.json 종속성을 수동으로 추가하는 경우) Yarn은 package.json 의 제약 조건을 충족하는 최신 버전을 사용할 수 있습니다. 결과는 yarn.lock 됩니다.

yarn.lock 이 업데이트되지 않도록하려면 --frozen-lockfile .

위에서 언급 한 최적화가 발생할 수 있으므로 문서가 잘못되었거나 당분간 고려해야 할 버그입니까?

추신. 여전히 발생하고 yarn --frozen-lockfile 는 실패하지 않습니다.

저는 현재 .yarnrc 파일에서 --frozen-lockfile 를 사용하고 있습니다. 다른 컴퓨터에서 yarn install 를 실행할 때 yarn이 yarn.lock 파일을 수정하는 것을 효과적으로 방지합니다. 그러나 이것은 또한 yarn add blahblah 가 내 yarn.lock을 수정하는 것을 방지합니다. 그게 올바른 행동입니까, 아니면 뭔가 놓치고 있습니까? 전체 스레드를 읽었으며 지금은 --frozen-lockfile 가 권장되는 접근 방식 인 것 같습니다.

@konekoya 예, 현재 반드시 사용해야하는 것이 맞습니다.

yarn install --frozen-lockfile

.yarnrc 의 설정에 의존하면 yarn.lock 이 업데이트되지 않습니다.

.npmrc 및 .yarnrc 의 콘텐츠에 따라 사용할 수 있습니다.

yarn install --no-default-rc {dependency}

그러나 나는 그것에 의존하지 않을 것입니다 (rc 파일에 다른 설정이 생기 자마자 중단되기 때문입니다.)

내 의견 과 관련 문제를 참조하십시오 : # 4570, esp. 내 결론 .

@ k0pernikus를 정리해 주셔서 감사합니다. 오늘은 진짜 너 덕분이다 :)

@BYK 왜 yarn은 add / upgrade 가 실행될 때가 아니라 yarn install yarn.lock 에 최적화를 적용합니까?

여기에 @ spencer-brown의 의견이이 문제를 "해결"하는 열쇠라고 생각합니다. 방금 직접 테스트하고 yarn upgrade 를 실행 한 다음 yarn "이미 최신 상태입니다."라는 메시지를 받았습니다. 내 삭제 그래서 node_modules 달렸다 yarn 내가로부터받은 일을 추진했다면 다음 내 프로젝트의 다른 DEVS가 종료 한 것 "최적화"잠금 파일로 이어지는 yarn upgrade .

이제 yarn upgrade (및 yarn add )가 yarn install 와 동일한 최적화를 실행한다면 처음에는이 문제가 발생하지 않을 것입니다. 기존 기능을 중단하고 싶지 않다는 이야기가 많았고 yarn upgrade 및 yarn add 이후에 최적화를 실행하는 것이 무언가를 중단하는 것으로 보지는 않습니다.

해결 방법으로 모든 개발자에게 잠금 파일을 다른 사용자에게 푸시하기 전에 "최적화"를 수행하도록 잠금 파일을 업데이트해야 할 때마다 node_modules를 삭제하도록 지시 할 생각입니다. 아니면 그들은 yarn upgrade && yarn prune 실행할 수 있습니다-아마도 그것이 트릭을 할 것입니까?

해결 방법으로 모든 개발자에게 잠금 파일을 다른 사용자에게 푸시하기 전에 "최적화"를 수행하도록 잠금 파일을 업데이트해야 할 때마다 node_modules를 삭제하도록 지시 할 생각입니다. 아니면 yarn upgrade && yarn prune 실행할 수 있습니다.

업데이트 : prune을 수동으로 실행할 수 없습니다. 다음 메시지가 표시됩니다. _ "prune 명령이 필요하지 않습니다. yarn install 은 (는) 불필요한 패키지를 제거합니다."._ 그리고 다음과 같은 이유로 install을 실행할 수 없습니다. _ "이미 최신 상태"입니다. node_modules를 삭제 한 다음 yarn 를 실행하여 정리를 수행 할 것 같습니다.

저에게 yarn 가장 큰 판매 포인트는 예측 가능하고 안정적인 잠금 파일 동작입니다. yarn install 의 잠금 파일을 변경하면 정말 걱정이됩니다.

저에게 yarn 가장 큰 판매 포인트는 예측 가능하고 안정적인 잠금 파일 동작입니다. yarn install 의 잠금 파일을 변경하면 정말 걱정이됩니다.

잠금 파일은 설치 될 항목의 정확한 사양으로 제공되므로 설치 될 항목에 대해 걱정할 필요가 없습니다. 동일한 잠금 파일을 사용하면 매번 동일한 설치를 받게됩니다. 그러나 때때로 yarn 는 자체적 인 이유로 경고없이 잠금 파일 내용을 변경합니다. 예, "파일 변경은 설치 될 내용을 변경하지 않는다"고 주장 할 수 있지만, 왜 그렇게 분명한 보증을하고 혼란스럽게 만들까요? 변경된 잠금 파일을 다시 커밋해야하는지 궁금해하는 이유는 무엇입니까? 왜 명성에 대한 당신의 주요 주장을 설리합니까?

이것은 정말 믿을 수없는 일입니다. 다른 사람들은 이미 그것을 잘 언급했습니다. 잠금 파일은 설치시 변경되지 않아야합니다. 이는 커밋 워크 플로에 부정적인 영향을 미칩니다. 우리 팀의 모든 개발자는 어떤 상황에서 잠금 파일이 변경 될 수 있는지 알고 있습니다. 종속성이 업데이트되지 않고 잠금 파일이 변경되면 불필요한 혼란과 추가 검사가 발생합니다. 방금 고장난 기본 패키지 관리자 UX입니다. 고쳐주세요.

Node.js 13에서 14로 이동할 때 yarn install 수행 할 때 모든 yarn.lock 파일이 변경된이 동작에 놀랐습니다.

어떤 식 으로든 yarn.lock 파일을 _optimizing_하면 경고를 내보내는 것이 적절한 동작이라고 생각합니다.