Yarn: 경쟁 잠금 파일로 인해 불량한 UX 생성

package.json에 구성을 추가하여 표시하십시오.

engine 필드에 대한 좋은 사용 사례가 될 수 있습니다 🤔

왕복 package-lock.json → yarn.lock → package-lock.json 는 손실이 있지만 중요하지 않을 수 있습니다. yarn.lock → package-lock.json → yarn.lock 는 손실이 없어야합니다, AFAIK.

npm 관점에서 저는 yarn 가 package-lock.json 를보고 yarn.lock 를 가져 와서 package-lock.json 제거하는 옵션을 선호합니다 npm 에 yarn.lock 되고 package-lock.json 없으면 동일한 작업을 수행하여`yarn.lock을 가져오고 제거합니다.

이렇게하면 두 도구의 사용자가 사용자의 프로젝트를 혼란스러운 상태 (파일이 둘 다에있는 것처럼 보임)에 두지 않고 원활하게 앞뒤로 전환 할 수 있습니다.

이것은 package-lock.json 도 yarn.lock 도 메타 데이터를 파일에 추가 할 수 없다는 것을 의미하기 때문에 약간 우려됩니다 (Yarn은 현재 지원하지 않지만 그 이유는 무엇입니까). 그 과정에서 우리 형식에 대한 자유.

사용자가 그 기대를하기 때문에 내가 모든 것을 정확히 동일한 방식으로 작동합니다, 우리 모두를받을 자격이 있습니다도 상호 운용이 가능하도록 노력 느낌 -이 문제는 원사와 NPM 일반적으로, 원래 다른 스레드에서 논의 간의 상호 운용성의 문제를 제기 두 프로젝트 모두 위험한 가정이라고 생각합니다 (한 가지 분명한 예는 누군가가 작업 공간 기반 프로젝트에서 npm을 실행하면 작업 공간이 조용히 중단된다는 것입니다).

@ yarnpkg / core, 생각?

두 도구 모두 하나의 잠금 파일에서 다음으로 마이그레이션하는 @iarna의 아이디어가 마음에 듭니다.
자동으로 설치됩니다.
마이그레이션 후 가져온 잠금 파일을 삭제하는 것이 좋습니다.
하나의 프로젝트에서 두 패키지 관리자가 경쟁합니다.

두 도구 모두 경고를 인쇄 할 수 있으며 계속 진행하라는 사용자 프롬프트가 필요할 수 있습니다.

또한 100 % 호환성을 달성하면 잠금이된다는 Mael의 요점에 동의합니다.
우리가 새로운 기능을 탐색하는 것을 막기 위해 일회성으로 처리해야한다고 생각합니다.
마이그레이션 경로는 우리의 install.js에있는 다소 작은 기능 일 수 있습니다.
측면.

2018 년 4 월 11 일 수요일 오후 9:49 Maël Nison [email protected] 은 다음과 같이 썼습니다.

나는 이것에 약간 관심이 있습니다.
package-lock.json 또는 yarn.lock은 파일에 메타 데이터를 추가 할 수 있습니다.
(Yarn은 현재 그렇지 않지만 그 이유는 아닙니다), 형식에 대한 자유를 제거합니다.
진행중.

이 문제는 또한 Yarn과 Yarn 간의 상호 운용성 문제를 제기합니다.
일반적으로 npm은 원래 다른 스레드에서 논의되었습니다.
상호 운용성이 너무 높다는 것은 사용자가
모든 것이 둘 다에서 똑같은 방식으로 작동 할 것이라는 기대를 가지고
위험한 가정이라고 생각하는 프로젝트입니다 (한 가지 분명한 예는
누군가가 npm을 실행하면 작업 공간이 조용히 중단됩니다.
작업 공간 기반 프로젝트).

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core , 생각?

—
언급 된 팀에 속해 있기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
.

몇 주 전에 "다른 잠금 파일 변환"솔루션 구현에 관심을 표명 했기 때문에

핑 감사합니다!

예, 저는 실제로 이것에 대해 정확히 작업하는 중입니다. 다음 주에 원사 RFC를 작성하고 모든 이해 관계자를 핑할 계획이었습니다.

간단히 말해서 yarn.lock <==> package-lock.json 변환 작업을 수행했습니다. 이 과정에서 약간의 손실이 있지만 논리적 인 손실은 거의 없습니다. 제 눈에는 위에서 언급 한 '일회성 변환'시나리오에 대해 이야기하고 있다면 이것은 완전히 수용 가능합니다. 이에 대해 더 자세히 논의하고 싶다면 더 자세히 설명하겠습니다.

현재이 작업을 수행하는 기본적인 코드가 있습니다. https://github.com/imsnif/synp
100 %가 아니며 변환 할 프로젝트의 기존 및 현재 node_modules 폴더에 의존합니다. 나는 레지스트리에서 패키지 상태를 가져 오는 재 작성 ( 2.0.0 지점에서)의 마무리 단계에 있습니다 (멋진 pacote lib 사용).

이 작업이 완료되면 yarn 및 npm 모두에서 정확히 어떻게 구현하고 싶은지에 대해 이야기하기 시작합니다.

이것에 대한 모든 사람의 생각을 듣고 싶습니다.

제 눈에는 위에서 언급 한 '일회성 전환'시나리오에 대해 이야기하고 있다면 이것은 완전히 수용 가능합니다.

그렇게 흔하지 않을 것 같습니다. 내가 틀렸을 수도 있지만 더 일반적인 사용 사례는 Yarn을 사용하는 프로젝트이며 개발자 중 한 명이 README에서 명령을 복사 / 붙여 넣기하여 yarn 대신 npm 를 사용하여 종속성을 추가합니다. yarn 처리 중입니다.

이 맥락에서 나는 올바른 일을 시도함으로써 조용히 데이터를 잃고 패키지 레이아웃을 변경하는 것이 좋은 일이라고 확신하지 못합니다. 그들은 아마 일이 깨질 때까지 그것을 알아 채지 못할 것입니다 (확인 프롬프트가있을 수 있지만 나는 그 명령을 복사 / 붙여 넣기하는 사람들이 맹목적으로 설치 프롬프트를 확인하기를 기대하고 있습니다). 더 나쁜 것은 자신의 컴퓨터에서 작동하지만 Yarn으로 다시 전환하면 동료의 컴퓨터에서 작동하지 않을 수 있다는 것입니다.

@arcanis- 모든 시나리오와 엣지 케이스에 대해 논의 할 가치가 있다고 생각합니다. 언급 한 시나리오에서 나는 매우 동의하지만 하나의 잠금 파일에 대한 명확한 편견이 있어야하는 다른 시나리오가 있다고 생각합니다.

이 기능은 주로 CI 환경에서 사용되는 것으로 보는데, OP가 언급했듯이 빛날 수 있다고 생각합니다. 적어도 두 도구가 다른 도구의 잠금 파일을 알고 있어야한다고 생각합니다. 그들이 전환을 결정하는시기에 대한 세부 사항은 그들에게 맡기십시오. 어떻게 생각해?

이 기능은 주로 CI 환경에서 사용되는 것으로 보는데, OP가 언급했듯이 빛날 수 있다고 생각합니다.

예가 있습니까? CI 시스템은 매우 결정적인 방식으로 작동해야합니다. 실수로 변환 된 잠금 파일을 커밋하는 것은 PR-time imo에서 더 나쁘게 잡혀야합니다. CI는 이것에 너무 늦습니다.

적어도 두 도구가 다른 도구의 잠금 파일을 알고 있어야한다고 생각합니다.

아마도. engine 버전을 사용하여 특정 패키지 관리자를 더 깔끔하게 보이게하려면 두 프로젝트 모두 독점 엔진 목록을 유지해야합니다 (예 : "yarn"은 "npm"에서 만족할 수 없으며 그 반대).

내 생각에 잠금 파일을 즉석에서 변환하는 것도 확장 성이 매우 낮습니다. 예를 들어, 지금까지 package-lock.json 파일에 대해서만 이야기했지만 pnpm에는 shrinkwrap.yaml 라는 자체 잠금 파일이 있다고 생각합니다. 둘 다 처리 할 수있는 방법과 하나의 돌로 나올 수있는 다른 형식을 찾을 수 있으면 좋을 것입니다.

이 기능은 주로 CI 환경에서 사용되는 것으로 보는데, OP가 언급했듯이 빛날 수 있다고 생각합니다.

또한 내가 올바르게 이해했다면 npm은 현재 CI에 특화된 매우 가벼운 패키지 관리자에서 작업하고 있으며 잠금 파일 변환기와 같은 무거운 비즈니스 로직이 필요한 작업에서는 잘 작동하지 않을 수 있습니다.

CI 관련 :
내 초기 생각은 : 반대 도구로 새 패키지를 추가 할 때 경고, 새로 설치할 때 변환 (또는 더 보수적으로 : 새 설치에서 기본적으로 실패하고 import 명령 또는 구성 플래그를 통해 변환을 자세히 허용) 설치용).

이전에 혼합 된 npm / yarn 환경에서 작업했을 때 기본적으로 git 히스토리를 사용하여 수동으로이 작업을 수행했습니다. 힘든 과정이었고 우리가 혼자가 아니었다 고 확신합니다.

확장 성 :
이것도 설명하고 싶습니다.
변환이 수행되면 중간 논리적 및 물리적 패키지 트리 (잠금 파일에있는 경우)가 생성됩니다. 원하는 잠금 파일로 변환 할 때 해당 트리가 사용됩니다 (또는 yarn 에서 변환하고 물리적 트리가없는 경우 정상적인 기본값으로 생성됨).
이렇게하면 다른 잠금 파일 유형간에 쉽게 변환 할 수 있습니다 (우리가해야 할 일은 각 유형에 대해 논리적 / 물리적 트리로 /에서 변환을 제공하는 것뿐입니다).

이것은 분명히 현재 도구의 기능보다 약간 앞서 있지만 이것을 구현하는 것이 큰 문제라고 생각하지 않습니다.

(npm의 새로운 ci 도구에 관해서는-무슨 뜻인지 알지만 이것이 현재 논의보다 조금 앞서 있다고 생각합니까?)

또는 더 보수적으로 : 새로 설치할 때 기본적으로 실패하고 가져 오기 명령을 통해 변환을 자세히 허용합니다.

예, 저는이 변환 로직을 yarn import 명령에 완전히 추가 할 것입니다. Yarn 플러그인을 구현할 경우 별도의 패키지로 추출 할 수있는 유용한 기능인 것 같습니다. :) 내 의견은 다음과 같습니다. 우리가 채택해야하는 기본 동작에 초점을 맞추고 있습니다.

npm@6 에서는 먼저 설치를 실행하지 않고도 package-lock.json -> yarn.lock 손실없이 변환 할 수 있습니다. 필요한 모든 데이터, 식별자 등을 포함해야합니다 (npm @ 6 의 pkglock에는 requires 필드에 버전 범위가 있으며 yarn.lock 사용하는 것과 일치합니까?)

아, 그리고 당신은 또한 필요 https://github.com/yarnpkg/yarn/pull/5042 NPM은이 없기 때문에,이뿐만 아니라, 사실 전에 배송에 sha1 다양한에서 pkglock의를 케이스.

@arcanis- 환상적입니다! 그래서 PR은 다음과 같습니다.

1. package-lock.json 파일을 설치하고 찾을 때 경고
2. package-lock.json 파일을 추가하고 찾을 때 경고
3. import 명령을 통해 package-lock.json 에서 변환하는 기능 추가 (및 이후 파일 삭제)
   수용 가능합니까? (그래서 우리는 구체적인 대화를 시작하는 데 사용할 수있는 것이 있습니다)

@zkat- npm@6 대단합니다! 나에게 달려 있다면 모든 잠금 파일 버전을 지원하기 위해 그것을 사용하고 매니페스트 파일로 폴백하는 것을 선택합니다. npm 대해 비슷한 (또는 다소 다른) 동작을 구현할 수 있는지 물어볼 수 있습니까?

또한 내가 올바르게 이해했다면 npm은 현재 CI에 특화된 매우 가벼운 패키지 관리자에서 작업하고 있으며 잠금 파일 변환기와 같은 무거운 비즈니스 로직이 필요한 작업에서는 잘 작동하지 않을 수 있습니다.

"현재 작업 중"이 "배송 완료"를 의미하면 예. =)

당신이 제안했듯이, 현재 yarn.locks 로딩은 그 범위를 벗어납니다 (패키지 트리를 레이아웃하는 방법을 모르기 때문에).하지만 우리 모두가 그 레이아웃을 할 수있는 라이브러리로 끝났다면 로딩을 지원하는 것에 반대하지 않습니다 yarn.locks. (이상적으로 이것은 Yarn과 공유되는 라이브러리 일 것입니다.) 분명히 기존 잠금 파일을 제거해서는 안됩니다. 패키지 메타 데이터에 관한 한 순전히 읽기 전용입니다.

package-lock.json 파일을 설치하고 찾을 때의 경고

지원되지 않는 종류의 잠금 파일이있을 때 경고를 표시하는 것만으로 는 Heroku가 가지고있는 않을까 걱정 됩니다.

지원되지 않는 종류의 잠금 파일이있을 때 경고를 표시하는 것만으로 는 Heroku가 가지고있는 않을까 걱정 됩니다.

경고는 개선이 될 수 있지만 메시지가 좋은 오류는 imo 사용자에게 이상적입니다. 나는 나 자신을 위해서만 말할 수 있지만, 몇몇 프로젝트는 yarn을 사용하고 일부는 npm을 사용하며 종종 그 프로젝트에 대해 잘못된 것을 입력하는 것을 발견합니다. 빠른 오류는 처음부터 가지고 있어야하는 것을 즉시 사용할 수 있음을 의미합니다.

경고라면 크고 분명해야합니다. IME 사용자는 제대로 작동하는 한 패키지 관리자의 출력을 무시할 수 있도록 훈련되었습니다.

저는 초보 개발자에 대해 더 많은 경험을 가진 사람들에게 연락을했고, 막 시작하는 사람에게 그 경험이 어떻게 생겼는지에 대한 희망을 갖게 될 것입니다.

CI 시스템은 매우 결정적인 방식으로 작동해야합니다. 실수로 변환 된 잠금 파일을 커밋하는 것은 PR-time imo에서 더 나쁘게 잡혀야합니다. CI는 이것에 너무 늦습니다.

나는 동의한다. 이상적으로는 빌드 / CI 서비스에 도달 할 때 애플리케이션이 불확실한 상태가 아닙니다. 이 경우 빌드에 실패하지 않고 편하게 느낄 수있는 유일한 방법은 사용자가 package.json 선호도를 표시 할 수있는 허용 된 방법이있는 경우 였지만 그 솔루션은 사용자에게 더 많은 부담을줍니다.

지원되지 않는 종류의 잠금 파일이있을 때 경고를 표시하는 것만으로 는 Heroku가 가지고있는 않을까 걱정 됩니다.

사용자에게 실제로 Heroku를 푸시하기 전에 원하지 않는 일을하고 있다고 경고함으로써 도움이 될 것입니다. 실제로 숫자가 얼마나 변경 될지는 모르겠지만, 몇 주 안에 확인하고 더 나아갈 필요가 있는지 확인할 수 있습니다. 그리고 필요한 변경 사항이 상대적으로 적기 때문에 첫 번째 좋은 반복이 될 수 있습니다.

경고를 제안하는 사람들을위한 정직한 질문 : package-lock.json 가있는 동안 yarn install 또는 yarn add 를 실행하는 것이 실수가 아닌 상황 이 있습니까? npm install 및 yarn.lock

npm에서 Yarn으로 또는 Yarn에서 npm으로 마이그레이션하는 것이 생각납니다. 다른 패키지 관리자를 시도하고 싶을 때 마찰을 추가하는 것을 피하고 싶습니다.

또한 명심해야 할 한 가지는 경고와 오류가 상호 배타적이지 않거나 적어도 engine 필드와는 관련이 없다는 것입니다. 고정 된 패키지 관리자가없는 프로젝트는 경고를 인쇄 할 수 있고 고정 된 패키지 관리자가있는 프로젝트는 오류가 발생할 수 있습니다. 이러한 방식으로 사용자는 자신이 선택하고 그에 따라 package.json을 구성 할 때까지 한 패키지 관리자에서 다른 패키지 관리자로 자유롭게 전환 할 수 있습니다.

엔진 필드의 또 다른 장점은 어떤 버전의 패키지 관리자를 사용해야하는지 확실히 알 수 있다는 것입니다. 어딘가에서 구성 할 수 있다고 생각하지만이 시스템에서는 일반 워크 플로의 일부가 될 것입니다.

엔진 필드의 또 다른 장점은 어떤 버전의 패키지 관리자를 사용해야하는지 확실히 알 수 있다는 것입니다. 어딘가에서 구성 할 수 있다고 생각하지만이 시스템에서는 일반 워크 플로의 일부가 될 것입니다.

engine 필드가 있습니까 아니면 engines 를 참조하고 있습니까? engine 참조하는 문서를 찾을 수 없습니다. 내가 뭔가를 놓친다면 사과드립니다.

engines 필드에서 버전 지정을 지원합니다. https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

전의:

  "engines": {
    "npm": "5.6.x"
  }

사용할 패키지 관리자를 결정하기 위해 이것을 사용하여 몇 가지 우려 사항이 있습니다.

• 오늘날의 모습 : 사소한 수의 사용자가 npm 및 yarn 둘 다 정의했거나 npm 버전을 가지고 있지만 yarn.lock 있습니다. npm 및 yarn 의 향후 버전에서는이를 시행 할 수 있지만 자주 업그레이드하지 않는 사용자는 오랫동안 현재 버전을 계속 사용할 것입니다.

• 대부분의 사용자는이 구성을 건드리지 않습니다. 그들은 자신의 머신에 nodejs.org에서 다운로드 한 모든 것을 사용하더라도 Node 0.10 를 지정하는 오래된 상용구를 포크했습니다. 이로 인해 Heroku에서 사소한 문제가 발생합니다.

• 팀은 종종 설치 한 버전을 조정하지 않습니다. 그들이 설치 한 Node, npm 또는 얀의 버전은 종종 그들이 프로젝트를 시작했을 때 또는 그들 중 하나가 마지막으로 고장 나서 다시 설치하도록 강요했을 때 최신 버전입니다. 이것이 이상적이라는 것은 아니지만, 대부분의 npm / yarn 사용자가 초보자이며 이것은 시작하는 데 새로운 장애물을 추가한다는 것입니다.

예 : "예제 hello-world 프로젝트를 복제하고 https://nodejs.org 에서 Node를 다운로드했지만 작동하지 않았습니다."

즉, 도구가 엄격한 버전을 적용하고 engines 기록하면 사랑하고, 사랑하고, 사랑할 것입니다. 매일 보게되는 많은 오류를 방지 할 수 있지만 훨씬 더 큰 변화처럼 느껴집니다.

즉, 도구가 엄격한 버전을 적용하고 엔진에 기록하면 사랑하고 사랑하고 사랑할 것입니다. 매일 보게되는 많은 오류를 방지 할 수 있지만 훨씬 더 큰 변화처럼 느껴집니다.

AFAIK Yarn은이를 비활성화하는 플래그를 전달하지 않는 한이 필드를 엄격하게 적용합니다.

팀은 종종 설치 한 버전을 조정하지 않습니다. 그들이 설치 한 Node, npm 또는 얀의 버전은 종종 그들이 프로젝트를 시작했을 때 또는 그들 중 하나가 마지막으로 고장 나서 다시 설치하도록 강요했을 때 최신 버전입니다.

이것은 Yarn의 동일한 주요 버전에서 일관성을 보장하기 때문에 Yarn을 사용할 때 매우 위험합니다.

이것이 이상적이라는 것은 아니지만, 대부분의 npm / yarn 사용자가 초보자이며 이것은 시작하는 데 새로운 장애물을 추가한다는 것입니다.

Yarn (및 아이디어가 마음에 들면 npm)이 engines 필드에 "yarn": "^<current_version>" 항목을 추가하여 너무 많은 마찰없이 안전을 도입하는 것은 어떻습니까? yarn init , yarn import 하거나 처음부터 잠금 파일을 만들 때 자동으로 추가 할 수 있습니다.

Yarn에 대해 잘 모르지만 가장 좋은 해결책은 package-lock.json 파서를 Yarn에 추가하고 존재하는 경우 yarn.lock 만들지 않는 것입니다.

최종 목표는 Yarn과 npm간에 하나의 잠금 파일 형식을 공유하는 것이어야한다고 생각합니다.

@thatlittlegit https://github.com/yarnpkg/yarn/pull/5745 에 대해 알게되어 기쁩니다. (npm은 역으로 동일한 작업을 수행하므로 작업중인 잠금 파일의 종류 나 선택하는 도구가 중요하지 않은 위치에있게됩니다.)

추가 편집 : 단일 잠금 파일 형식은 잠금 파일 형식간에 서로 다른 장단점이 있고 어떤 형식이 가장 좋은지에 대한 합의가 없기 때문에 가능한 결과가 아닙니다. 두 도구가 서로의 잠금 파일을 서로 이해할 수 있으면 충분하다고 생각합니다.

그 외에도 단일 일반 솔루션으로 할 수있는 것보다 사용자 사용 사례를 더 잘 충족시킬 수 있다는 것을 의미하기 때문에 서로 다른 절충안을 만드는 여러 적극적으로 사용되는 도구를 사용하면 많은 이점이 있습니다.

@BYK 엔진 필드의 동작에 대한 몇 가지 기록이 여기에 도움이 될 것입니다.

npm @ 1 및 npm @ 2 에는 engine 필드 외에 engineStrict 라는 package.json engine 있습니다. engineStrict 가 true이면 engine 필드가 _resolution constraint_로 사용되었으며 버전 목록에 semver 범위를 적용하기 전에 호환되지 않는 엔진이있는 버전이 필터링됩니다. 이것은 당신이 같은 것들을 할 수 있도록 것입니다 npm install foo 얻을 [email protected] 경우에도 [email protected] 경우 게시 된 [email protected] 플랫폼에서 지원되지 않습니다. 이 _seems_ 바람직하지만 실제로는 매우 혼란 스러웠습니다. 특히 웹 사이트의 문서는 최신 버전에 대한 것이기 때문입니다.

engineStrict 가 false이면 엔진 필드에 관계없이 해결이 수행되고 결과가 호환되지 않으면 경고가 발생합니다.

package.json 속성과 동일한 작업을 수행하지만 모든 패키지에 적용하는 engine-strict 구성 옵션도 있습니다.

npm @ 3 부터 engineStrict package.json 속성에 대한 지원을 중단하고 engine-strict 구성 옵션의 동작을 변경했습니다. 이제 config 옵션이 해제 된 경고를 오류로 전환하지만 해결에는 영향을주지 않습니다.

engine 필드는 최상위 프로젝트에만 적용되는 것이 아니라 전 이적으로 적용됩니다. yarn 엔진 플래그를 도입하면 종속성이 yarn으로 만 설치 될 수 있음을 의미하며 여기에 해당되지 않는다고 생각합니다.

다음 yarn 릴리스부터 package-lock.json 를 yarn.lock 로 가져올 수 있어야합니다. 다시 경고 / 오류 문제에 대해 논의하고 싶습니다.

내가 보는 방식 : 단일 패키지에 package-lock.json 과 yarn.lock 파일이 모두 있어야하는 타당한 이유가 없다고 생각합니다. 내가 고의로 이것을 원하는 상황이 아닌 수정해야 할 문제로 보는 대부분의 프로젝트를 보았습니다 (물론 수정할 수 있습니다).
위의 @iarna 설명에서 알 수 있듯이 engine 필드는 패키지가 사용중인 패키지 관리자를 명시 적으로 지정하는 좋은 솔루션이 아닙니다.
따라서 IMO는 사용자가 하나의 파일을 삭제하거나 변환하도록 초대하는 자세한 오류를 생성해야하는 상황입니다.

그러나 그러한 오류를 생성하는 것은 분명한 주요 변경 사항이라고 생각합니다. 실 측에서는 경고 (위에서 언급했듯이)로 시작하여 오류로 변경 될 다음 메이저 버전까지 천천히이 동작을 사용하지 않을 것을 제안합니다 (두 파일을 모두 허용하는 구성 플래그를 추가 할 수 있음). 동시에 존재).

다들 어떻게 생각하세요? @jmorrell , @BYK , @arcanis , @iarna?

어떤 종류의 프로젝트에서 어떤 패키지 관리 도구를 사용해야하는지 지정해야한다는 것이 이상하게 보입니다. 내가 틀렸다면 정정하십시오. 그러나 Yarn은 대부분 최종 사용자 선호도에 달려있는 드롭 인 대체품으로 간주됩니다. Yarn은 사실상의 표준으로 NPM을 완전히 대체하려고합니까, 아니면 공존하려고합니까?

@BrainBacon 모든 사람이 동일한 잠금 파일을 존중하고 동일한 의미를 사용하는 동일한 패키지 관리자를 사용하는 경우에만 잠긴 종속성의 이점을 얻을 수 있습니다. 프로젝트에 yarn.lock 있고 누군가가 npm install 를 실행하는 경우 해당 사용자는 여전히 다른 종속성 세트로 끝날 수 있습니다. 따라서 최종 사용자의 선호도에 의존하지 않습니다. 불행히도 프로젝트의 모든 사람이 동일한 패키지 관리자를 사용하는 것이 좋습니다.

이것은 또한 프로젝트에 두 개의 잠금 파일이있는 것은 의미가 없음을 의미합니다. 그들은 동일한 의존성 트리로 해결 될 가능성이 낮으며 어떤 패키지 관리자를 사용할지 기여자에게 불분명하게 만듭니다.

(드롭 인 교체 부품은 npm이 잠금 파일을 생성하지 않았을 때 특히 사실이었습니다. 그곳에서 잃어 버릴 정보가 없었기 때문입니다. # 5745가 실제로 Yarn이 package-lock.json 기반으로 잠금 파일을 생성 할 수 있다는 것을 의미하는 경우에도 여전히 사실입니다

내가 틀렸다면 정정하십시오. 그러나 Yarn은 대부분 최종 사용자 선호도에 달려있는 드롭 인 대체품으로 간주됩니다.

Yarn은 노출 된 API 측면에서 직접 드롭 인 대체품이 아닙니다. yarn add <pkg> 대 npm install <pkg> 는 우리가 일을 다르게하는 명백한 예입니다. 우리는 동일한 기능 세트를 갖는 경향이 있지만 결국에는 두 가지 다른 도구이며 때로는 동일한 문제에 대한 다른 솔루션이 있습니다.

yarn.lock 대 package-lock.json 는 이러한 차이점 중 하나이며 Yarn이나 npm은 서로 다른 정보를 포함하고 있기 때문에 단일 사용에 관심이 없다고 생각합니다.

원사 쪽에서는 경고 (위에서 언급했듯이)와 함께 시작하는 것을 제안합니다.

나는 이것으로 괜찮을 것입니다. 다음과 같은 것 :

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

누군가 PR을 열고 싶습니까?

경고를 추가하는 PR을 열어 드리겠습니다. :)

package-lock.json + yarn import 이 (가) 존재할 때 원하는 최종 솔루션이 여기에 유용한 오류입니까? 내 이해는 @iarna 가 각 도구가 자동으로 존재하는 경우 반대 잠금 파일을 제거 / 변환해야한다고 주장하고 있다는 것입니다.

어느 쪽의 솔루션이든 사용자에게는 상당한 개선이 될 것이지만, yarn과 npm이 동일한 전략을 선택하는 것이 가장 좋을 것이라고 생각합니다.

@jmorrell- 내 이해는 여기서 자동 변환이 나쁜 생각이라는 데 동의했다는 것입니다.

주로 두 잠금 파일 사이의 델타가 무엇인지 알기가 어렵 기 때문입니다.
예 : 개발자로서 위의 경고가 표시되면 다른 잠금 파일이 언제 생성되었는지, 기본 잠금 파일에 추가되지 않은 패키지가 추가되었는지 파악한 다음 추가하고 싶을 것입니다. import 옵션을 참조로 사용할 수도 있지만 반드시 그런 것은 아닙니다.

나는 npm 사람들이 이것에 동의하기를 바랍니다?

이상적으로는이 경고가 더 이상 사용되지 않는 상황 (어휘에 대해 확실하지 않음)이고 향후 원사 버전에서 오류가 발생할 것이라는 내용을 포함하고 싶습니다. 이것에 대한 자세한 문서와이를 해결하는 방법에 링크 할 수 있습니다. @arcanis- 실현 가능하다고 생각 warning 행동을 유지 하시겠습니까?

잠금 파일이 여러 개있을 때 두 도구 모두 error 발행하는 경우 개발자는이 문제가 여전히 "작지만"이 문제를 파악하고 신속하게 해결할 수 있다고 생각합니다 (참조로 가져 오기 또는 사용하지 않고 가져 오기). .

@arcanis npm add <pkg> 은 완벽하게 유효하며 Yarn이하는 일을합니다 👼

pkglock과 yarnlock에 관한 한 package-lock.json 의 원래 의도는 패키지 관리자가 필요로하는 모든 데이터를 포함하는 형식을 만드는 것이 었습니다. 실제로 npm@6 의 pkglock은 모든 관련 메타 데이터가 포함 된 전체 트리를 설명하므로 설치 프로그램을 실행하지 않고도 yarn.lock으로 투명하게 변환 될 수 있습니다. _ 의도적으로 _ (예 : requires 필드) 수행했으며 Yarn 및 pnpm 팀 모두에게 피드백을 요청하여 우리가 한 작업이 둘 다 가져 오기 가능한 잠금 파일로 사용하거나 대체 옵션으로. yarn.lock은 안타깝게도 손실이있는 부분 집합이므로 역은 사실이 아니지만 어쨌든 가져 오기 위해 물건을 추가 할 것입니다. npm은 Yarn이 계산 한 트리 모양을 따르기도합니다 (Yarn과 달리).

실제로 npm @ 6 의 pkglock은 모든 관련 메타 데이터가 포함 된 전체 트리를 설명하기 때문에 설치 프로그램을 실행하지 않고도 yarn.lock으로 투명하게 변환 될 수 있습니다.

나는 그것이 할 수 있다고 생각하지 않는다 (그러나 내가 착각했을 수도있다. 어떤 오해라도 자유롭게 지적한다). Yarn 잠금 파일은 단일 버전으로 확인되는 다중 범위를 설계 상 지원하지 않습니다. lodash@^1.0.0 에 따라 각각 여러 패키지가있는 경우 모두 정확히 동일한 버전을 사용합니다. 이는 최적화 일뿐만 아니라 잠금 파일에서 인코딩하는 방법이기도합니다.

npm 잠금 파일은 트리이므로이 속성은 보장되지 않으며 여러 동일한 범위가 다른 버전을 사용하게 될 수 있습니다 (노드 확인 규칙을 활용하여 약간 더 나은 최적화를 허용 할 수 있으므로 괜찮습니다). 이러한 상황에서 package-lock.json-> yarn.lock 변환은 손실이 발생할 수 있습니다. 단일 변환으로 병합하는 것 외에는 다른 선택이 없기 때문입니다.

반면에 Yarn 잠금 파일은 상대적으로 문제없이 package-lock.json으로 변환 될 수 있습니다. 왜냐하면 우리의 규칙은 더 엄격한 하위 집합이기 때문입니다 (우리의 병합 된 범위는 손실없이 트리로 변환 될 수 있으며 트리는 손실없는 병합 된 범위). 저는 종속성 트리 자체에 대해서만 이야기하고 있으며 메타 데이터 필드에 익숙하지 않습니다.

솔직히 말해서 우리가 똑같은 말을하는지 완전히 다른 말을하는지 완전히 확신하지 못합니다. 상황을 조금 명확히하고 싶었습니다.

이상적으로는이 경고가 더 이상 사용되지 않는 상황 (어휘에 대해 확실하지 않음)이고 향후 원사 버전에서 오류가 발생할 것이라는 내용을 포함하고 싶습니다. 이것에 대한 자세한 문서와이를 해결하는 방법에 링크 할 수 있습니다.

@imsnif 나는 이것이 비 CI 환경에서 오류라고 확신하지 않습니다 (CI에 대한 질문이 없습니다-이것은 확실히 오류를 유발해야합니다). 나는 단순히 현재 상태를 설명하고 그것이 이상적이지 않은 이유를 설명하는 경고에 머물기를 선호합니다.

좋은 점은 @jmorrell 이 경고가 충분했는지 여부를 알 수있는 정확한 지표를 제공 할 수

여기서 원하는 최종 솔루션은 package-lock.json이 존재하고 실을 가져올 때 유용한 오류입니까?

네, "CI에서 오류로 업그레이드"모드 *와 결합하여 합리적인 첫 단계라고 생각합니다!

(* 아직 존재하지 않습니다. # 5773 Yarn 2.0 WG에서 언급하겠습니다.)

@arcanis - 파일 잠금 소개 : 나는 @zkat가 참조 무슨 생각 (하지만 내가 틀렸다거나 오해하는 경우 올바른 나 @zkat하시기 바랍니다) 즉 package-lock.json 잘 논리적 트리로 같은 물리적 저장하는 동안 yarn.lock 는 논리 트리 만 저장합니다. 따라서 앞서 언급했듯이 package-lock.json => yarn.lock => package-lock.json 하면 물리적 트리 데이터가 손실됩니다. 대부분의 경우 IMO는 괜찮지 만 예외가 있습니다. 번들 종속성.

내 개인적인 의견은 두 패키지 관리자 모두 물리적 트리 구성을 동기화함으로써 이익을 얻을 수 있다는 것입니다. 내가 본 것에서 우리는 물리적 트리가 생성되는 방법에 대해 잘 정의 된 규칙을 추출하고 둘 다 (이상적으로는 모든 이해 관계자가 유지 관리하는 모듈을 사용하여)이를 따를 수 있습니다. 나는 이것이 둘 다 호환성 문제를 해결할 것이라고 생각한다. yarn 가 번들로 묶인 의존성과 함께 가지고있는 일부 문제는 여전히 각 패키지 관리자가 고유 한 특성을 유지할 수 있도록 허용한다. (확실히, 나는이 토론을 처음 접했기 때문에 내가 모르는 것이있을 수 있습니다. 잠자는 개를 깨우면 사과드립니다).

하지만 당면한 문제에 대해 :
CI 수준에서이를 포착하는 것이 실제로 매우 중요하지만 개발자의 로컬 환경에서 발생하는 오류보다 (평균적으로) 디버그하기가 훨씬 더 어려울 것이라고 생각합니다.
개발자가 잘못된 도구를 사용하여 로컬 환경에서 오류가 발생하면 한 단계도 더 나아 가지 않을 것입니다. 그들은 "죄송합니다"라고 말하고 다른 도구를 사용합니다. 기능을 개발 한 후 역 추적을 수행 한 후 CI에서 포착하는 대신 엄청난 시간을 절약 할 수 있습니다.
경고 (앞에서 언급했듯이)는 종료 상태가 0 인 경우 개발자가 무시하는 경향이있는 다른 많은 경우에 삼켜 질 수 있습니다.
어떻게 생각해?

또한-위에서 설명한 상황에서 "외부"잠금 파일이 .gitignore 위치 할 수 있으므로 CI가 이에 대해 알 기회조차 얻지 못할 것입니다. 멍청한 개발자로서 "글쎄, 내 로컬 환경에 대한 모호한 경고를 제공하지만 CI를 통과합니다. 그래서 아마 내 쪽의 로컬 문제 일 것입니다. 아 글쎄"라고 생각할 수 있습니다.

경고 (앞에서 언급했듯이)는 종료 상태가 0 인 경우 개발자가 무시하는 경향이있는 다른 많은 경우에 삼켜 질 수 있습니다.

내 요점은 정보에 입각 한 결정을 내릴 수있는 일부 정보를 수집 할 수있는 방법이 있지만이 확인은 데이터에 의해 뒷받침되지 않는다는 것입니다. 이런 맥락에서 사람들의 작업 흐름 을 깨뜨릴 더 급진적 인 옵션을 선택하는 것은 나에게 약간 헛되고 잠재적으로 해로운 것 같습니다 😕

또한 "패키지 관리자를 사용하고 있고 다른 것을 시도하고 싶습니다"라는 사용자 스토리를 간과하고 있다고 생각합니다. 이는 패키지 관리자 관리자와 사용자 모두에게 매우 중요하다고 생각합니다. 사람들이 Yarn 프로젝트에서 npm 6을 쉽게 사용해 볼 수 없다면 (또는 반대로 npm 프로젝트에서 Yarn을 사용해 볼 수 없다면) 좋지 않을 것입니다.

내 개인적인 의견은 두 패키지 관리자 모두 물리적 트리 구성을 동기화함으로써 이익을 얻을 수 있다는 것입니다.

이것은 다른 주제이지만 동의하지 않습니다. Yarn이 npm이라는 오해가 있다고 생각합니다. 전용 명령을 통해 프로젝트를 다른 프로젝트로 가져 오려는 경우에는 모두 할 수 있지만 타사 형식에서 잠금 파일을 자동으로 변환 (또는 읽는)하는 것은 재난을위한 레시피입니다.

• 구성 파일을 무시합니다.
• 다음에 패키지가 추가 / 제거 될 때 물리적 트리가 손상됩니다.
• 패키지 관리자에 고유 한 기능이 작동하지 않습니다 (작업 공간, 해상도 재정의, 링크 :, ...).

내 요점은 정보에 입각 한 결정을 내릴 수있는 일부 정보를 수집 할 수있는 방법이 있지만이 확인은 데이터에 의해 뒷받침되지 않는다는 것입니다. 이런 맥락에서 사람들의 작업 흐름을 깨뜨릴 더 급진적 인 옵션을 선택하는 것은 나에게 약간의 헛된 일이고 잠재적으로 해로운 혼란스러워 보입니다.

사실-데이터로 뒷받침되지 않습니다. 나는 여기에서 확실히 추측하고 있습니다 (이것을 강조하지 않았다면 죄송합니다). 경고 수정의 추세를 파악할 수는 있지만 이것이 사용자에게 얼마나 편리한 지, 더 편리한 솔루션이 있는지 여부는 파악할 수 없습니다. 우리가 데이터에 의존한다면 "Heroku 배포 오류율에는 전혀 변화가 없었습니다"라는 결과 외에는 포괄적 오류 솔루션으로 우리를 이끌 것이라고 생각하지 않습니다.

사람들의 워크 플로우를 깨지 않는 것이 매우 중요하다는 데 동의합니다. 그래서이 상황이 더 이상 사용되지 않음을 사용자에게 경고하는 경고 문구와 함께 2.0.0 의 주요 변경 사항으로 오류를 제안했습니다. 또한 --force 또는 config 매개 변수를 사용하여이 동작을 재정의 할 수 있다고 생각합니다. (나는 이것이 다른 패키지 관리자 문제를 시도하는 것도 해결한다고 생각합니까?)

이것은 다른 주제이지만 동의하지 않습니다. Yarn이 npm이라는 오해가 있다고 생각합니다. 전용 명령을 통해 프로젝트를 다른 프로젝트로 가져 오려는 경우에는 모두 다 할 수 있지만 타사 형식의 잠금 파일을 조용히 변환 (또는 읽는)하는 것은 재난의 비결입니다.

여기에서 제가 다루고 싶은 중요한 문제를 제기하신 것 같습니다. 그러나 당신이 말했듯이 이것은 다른 주제이며 나는 대화를 탈선시키고 싶지 않습니다. 별도의 문제에서 논의 할 수 있을까요?

여기에서 대화가 다소 탈선되었다고 생각하므로 몇 가지 설명과 요약으로 정리하고 싶습니다.

1. Yarn과 npm은 다른 해상도와 물리적 트리 생성 전략을 가지고 있으며 이것은 두 프로젝트가 존재하는 핵심 요소입니다.
2. yarn.lock 및 package-lock.json 파일은 모두 특정 목표를 염두에두고 생성되었으며 제가 볼 수있는 한 이러한 목표는 완전히 일치하지는 않지만 일부 중복됩니다.
3. 이러한 목표의 차이는 일반적으로 다른 형식보다 우수한 형식을 만드는 것이 아니라 다른 점을 상충합니다.

이를 바탕으로 두 형식을 모두 유지하는 것이 실제로 혁신과 다양한 요구 사항을 충족하는 데 중요하다고 생각합니다. 필요한 것은 무료 실험을 허용하기 위해 특정 패키지 관리자 전략을 다른 사람에게 부과하지 않고 패키지 관리자 간의 데이터 손실을 최소화하면서 프로젝트 이식성을 보장하는 것입니다.

다른 잠금 파일에 대한 승인 및 경고와 함께 보존되는 항목과 손실 된 항목에 대한 명확한 메시지가 각 측면의 사용자에게 큰 가치로 제공되는 적절한 변환과 함께 표시됩니다. 이제이 문제의 질문 은 사용자가 yarn을 실행할 때 저장소에 패키지 잠금 파일이있는 사용자에게 가장 적합한 흐름 이

자동 변환은 잠재적으로 위험하며 탈출구없이 설치에 실패하면 특정 사람들에게 해를 끼칠 수 있습니다. 패키지 잠금 파일을 갖는 것이 CI 모드에 있음을 알기 위해 yarn에 대한 구성을 설정하도록 요구하는 것은 어떻습니까? 이것은 개발자들이 "내가 뭘하는지 알고 있으니 어떤 불일치로부터 나를 보호하려고하지 말아 줘"라고 말하는 신호입니다.

생각?

패키지 잠금 파일을 갖는 것이 CI 모드에 있음을 알기 위해 yarn에 대한 구성을 설정하도록 요구하는 것은 어떻습니까? 이것은 개발자들이 "내가 뭘하는지 알고 있으니 어떤 불일치로부터 나를 보호하려고하지 말아 줘"라고 말하는 신호입니다.

@BYK- 좋은 소리입니다. 한 가지 추가 사항 : @arcanis가 여기와 했듯이 구성 플래그가 설정되지 않은 경우 non-ci 모드에서 경고를 추가하는 것도 좋습니다. 따라서 개발자는 푸시하기 전에 CI 빌드가 실패 할 수 있음을 알 수 있습니다 (또한 package-lock.json 이 .gitignore 것을 방지하기 위해).

@imsnif 가 언급 한대로 @arcanis : pkglock에는 트리의 논리적 및 물리적 레이아웃 _both_가 포함됩니다. 중복 제거 된 범위를 포함하는 트리의 논리적 버전을 따르면 설치 또는 설치 프로그램 논리를 전혀 실행하지 않고 메모리 내에서 yarn.lock을 구성 할 수 있습니다. 그냥 트리 조회 :)

NPM 5 릴리스 노트에서 :

패키지 관리자 간 호환성을위한 새로운 표준화 된 잠금 파일 기능 (package-lock.json)

NPM 팀은 package-lock.json 를 범용 솔루션으로 광고하는 것 같습니다. 그 세력에 (기술적으로) 합류하는 것이 가능합니까?

내가 제안하고 싶은 한 가지 해결책은 "이미 존재하는 경우 package-lock.json 만 사용"하는 것입니다. 이것이 기본적으로 NPM이 축소 포장에서 잠금 json 파일로 "마이그레이션"된 방법입니다.

NPM 팀은 package-lock.json을 범용 솔루션으로 광고하는 것 같습니다. 그 세력에 (기술적으로) 합류하는 것이 가능합니까?

우리는 이미 그것에 대해 논의했습니다. 그렇지 않은 경우 나머지 스레드를 확인하십시오. 이것은 단기적으로는 일어나지 않을 것입니다.

"패키지 관리자를 사용하고 있으며 다른 관리자를 사용하고 싶습니다"라는 사용자 스토리를 간과하고 계시다고 생각합니다. 이는 관련된 모든 사람에게 매우 중요하다고 생각합니다.

이것은 아마도 자주 발생하지 않는 컨텍스트 전환입니다. 나는 얼마 전에 Yarn을 선택했고 뒤돌아 보지 않았다. 잠금 파일이있는 이유의 심각성 뒤에 무게를 두는 것이 더 낫다고 생각합니다. 무시할 경고가 아니라 선택 해제 할 수있는 오류로 만드십시오. 누군가가 잠금 파일을 커밋하면 이유가 있습니다.

통계에 따르면 대부분의 Yarn 사용자는 npm도 사용합니다. Mixed _projects_는 흔하지 않지만, 여러 프로젝트에서 일하는 한 사람 (일부는 npm이고 일부는 Yarn)은 매우 일반적입니다. 문제를 더욱 복잡하게 만드는 것은 npm을 직접 실행하는 설치 스크립트입니다.

yarn을 사용하고 싶지만 제가 작업하는 대부분의 프로젝트에는 package-lock.json 파일 yarn.lock 파일을 추가 할 수 없습니다. yarn import 이 느리거나 손상되었습니다. 현재 내
_only_ 옵션은 실을 버리고 npm으로 전환하는 것입니다.

원 사는 원사 전용 프로젝트를 위해 원사 전용 개발자가 제작 한 것으로 알고 있습니다. 하지만 나머지 우리는 어떻습니까?

안녕하세요 @Spongman- yarn import 은 (는) 깨지지 않아야합니다. 이제 package-lock.json 를 가져올 수 있습니다. 문제가있는 경우 알려주십시오!

나는 # 6103

안녕하세요 @Spongman- 문제에 대해 언급했습니다.이 특정 사례는 손상된 package-lock.json 입니다. 다른 문제에 대해 알게되어 기쁩니다.

npm은 package-lock.json 파일을 잘 사용할 수 있습니다. 원 사는 더 탄력적이어야합니다.

다른 문제에서 이에 대한 답변-이 문제를 주제로 유지하기 위해 토론이 거기로 이동하도록 요청합니다. 감사!

https://github.com/yarnpkg/yarn/issues/3614 (현재 254 : +1 : s 포함)를주의 깊게보고 참여했습니다. 그 문제는 이제 종결되었고 토론은 여기로 옮겨졌습니다.

실질적인 도전을 무시하고, 내 생각에 최고의 UX는 상단의 요약에 언급되지 않았지만 @thatlittlegit이 언급 한 옵션에 의해 제공 될 것입니다.

최종 목표는 Yarn과 npm간에 하나의 잠금 파일 형식을 공유하는 것이어야한다고 생각합니다.

@BrainBacon 의 요점으로도 백업됩니다.

어떤 종류의 프로젝트에서 어떤 패키지 관리 도구를 사용해야하는지 지정해야한다는 것이 이상하게 보입니다.

다시 한 번, 실제 문제를 무시하고 이에 대한 이론적 반론은이 스레드의 @iarna (및 다른 스레드의 @jhabidas) 에 의해 작성 되었습니다.

사용자 사용 사례가 단일 일반 솔루션보다 더 잘 충족 될 수 있다는 것을 의미하기 때문에 서로 다른 절충안을 만드는 여러 개의 적극적으로 사용되는 도구를 보유하면 많은 이점이 있습니다.

개인적으로, 나는 다른 스레드 에 했던 것처럼이 주장이이 경우에 적용되어야한다고 생각하지 않습니다.

네 동의합니다. Yarn은 가능한 한 독립적 인 공간을 유지하기를 원하므로 더 나은 경험을 제공 할 수있는 유연성이 있습니다. 예를 들어 Yarn의 CLI가 의도적으로 NPM과 호환되지 않는 이유입니다.

하지만 락 파일은 Yarn이 합리적으로 독립성을 유지할 수있는 공간 밖에 있다고 생각합니다. package-lock.json 및 composer.lock package.json 및 composer.json package.json 및 composer.json 와 함께 저장소에 커밋됩니다 . 이러한 파일은 도구 별 파일이 아니라 프로젝트가 작동하도록 보장되는 정확한 종속성 버전을 지정하는 프로젝트 별 파일입니다.

...

Yarn이 유용한 도구가 되려면 개발자가 프로젝트에서 표준 모델을 따를 수 있어야 프로젝트가 도구에 구애받지 않고 유지 될 수 있습니다. 결국 Yarn이 별도의 종속성 파일이 아닌 package.json 위에 빌드 된 이유입니다.

이 스레드의 대부분을 읽었지만 여전히 초기 평가에 동의합니다. Yarn이 저장소에서 동일한 package.json 종속성 파일을 계속 사용한다면 이상적으로 동일한 package-lock.json 파일을 저장소로 내 보내야합니다. 이므로 저장소는 도구에 구애받지 않고 유지 될 수 있습니다. 원사부터 종속성 읽으면 yarn.json 대신 package.json 나는이 점을 계속하지 않을 것입니다.

이것이 이상적인 상황, 원활한 사용자 경험임을 인정해야한다고 생각합니다. 그러나 @iarna 의 다른 요점을 이해합니다.

단일 잠금 파일 형식은 잠금 파일 형식간에 서로 다른 장단점이 있고 어떤 형식이 가장 좋은지에 대한 합의가 없기 때문에 가능한 결과가 아니라고 생각합니다.

(저는 "두 도구가 서로의 잠금 파일을 상호 이해할 수있는 것으로 충분하다"는 데 동의하지 않지만).

도구에 구애받지 않는 리포지토리를 허용하는 이상적인 시나리오를 확실히 달성 할 수없는 경우 (다른 잠금 파일이 근본적으로 다른 방식으로 빌드되고 다른 정보를 포함하는 방법에 대한 많은 의견을 볼 수 있습니다), 우리가 가고있는 것처럼 보이는 곳은 맛있습니다.

• NPM / Yarn은 상대방의 잠금 파일을 발견하면 경고를 내 보냅니다 (그리고이를 오류로 만드는 구성 옵션).
• 두 도구 모두 잠금 파일을 다른 잠금 파일로 변환하는 메커니즘을 제공합니다.

어떤 상황에서도 다른 사람의 잠금 파일을 변환하고 삭제해서는 안된다고 생각합니다. 이것은 개발자가 어떤 도구를 사용하는지에 따라 새로운 개발자가 하나에서 다른 것으로 영원히 전환한다는 것을 의미합니다 (너무 많은 사람들이 git commit -a 커밋한다는 점을 감안할 때).

나는 또한 @imsnif 의 요점에 동의하지 않습니다.

단일 패키지에 package-lock.json과 yarn.lock 파일이 모두 있어야하는 타당한 이유가 없다고 생각합니다.

개발자가 자신의 컴퓨터 또는 프로덕션 환경에서 실행하는 작업을 지시하는 것은 주제 넘기 때문이라고 생각합니다. 최소한 당신이 필요로하는 것보다 더 제한적이지 않은 것은 예의입니다. 프로젝트가 개발자 팀에 의해서만 실행되고 모두 정확히 동일한 소프트웨어를 실행하고 있다면 좋습니다. 그러나 어떤 이유로 든 Yarn보다 NPM을 사용하는 것이 훨씬 더 쉽다고 생각하는 개발자가있을 수 있습니다. 특히 오픈 소스 소프트웨어를 만드는 경우 커뮤니티 구성원이 가능한 한 쉽게 시작하고 실행할 수 있도록해야합니다. NPM과 Yarn은 package.json 에서 동일한 종속성을 설치하기위한 단순한 도구이므로 제대로 작동해야합니다. 개발자는 package.json 를 볼 수 있고 해석 할 도구가 있어야하며 더 이상 걱정할 필요가 없습니다. 이 잠금 파일 충돌이 단독으로 발생하기 전의 경우였습니다.

안녕하세요 @nottrobin- 나는 당신이 어디에서 왔는지 이해한다고 생각합니다. 실제적인 도전과 철학적 차이를 무시한다면, 다양한 도구의 사용자가 모두 동일한 잠금 파일을 사용한다면 확실히 더 나을 것입니다 (물론 제 개인적인 의견입니다).

그러나 우리는 실질적인 도전을 무시할 수없고 대부분 철학적 차이가 그 자리를 차지한다는 데 동의 한 것처럼 보였기 때문에 우리가 찾은 타협 (위에서 설명한 것)은 확실히 "충분히 좋다"고 생각합니다.

이 절충안의 숨겨진 가정은 도구 선택이 개발자의 시스템 또는 프로덕션 환경이 아닌 프로젝트 당 하나라는 것입니다.

이 절충안의 숨겨진 가정은 도구 선택이 개발자의 시스템 또는 프로덕션 환경이 아닌 프로젝트 당 하나라는 것입니다.

네, 이것이 제가 가장 우려하는 부분이라고 생각합니다. 위에서 설명한 시나리오에서 프로젝트가 Yarn과 NPM을 모두 지원하는 것이 여전히 가능 하다고 생각합니다.

궁극적으로 두 프로젝트가 도구에 구애받지 않는 프로젝트를 허용하려는 임무를 포기하면 실제로 종속성 파일 공유를 중단해야한다고 생각합니다. 원사 읽기로 전환해야 yarn.json 보다는 package.json . 다른 것은 그냥 지저분하고 혼란 스럽습니다.

npm 잠금 파일에 Yarn 잠금 파일이 지원하는 종속성 관계의 상위 집합이 이미있는 경우 Yarn에서 둘 다 지원하지 않는 이유는 무엇입니까? Yarn은 package.json으로 전환 할 수 있으며 Yarn이 원하는 추가 필드는 향후 추가 될 수 있습니다 (잉크 스케이프와 같은 일부 SVG 편집기가 편집기 메타 데이터를 관리하는 방식과 유사). 그런 다음 Yarn은 npm과 동일한 종속성 형식을 가질 수 있으며 yarn.lock과 다시 호환되어 npm 잠금 파일을 Yarn이 메모리에서 원하는 구조로 변환합니다.

궁극적으로 두 프로젝트가 도구에 구애받지 않는 프로젝트를 허용하려는 임무를 포기하면 실제로 종속성 파일 공유를 중단해야한다고 생각합니다. 원사 읽기로 전환해야 yarn.json 보다는 package.json . 다른 것은 그냥 지저분하고 혼란 스럽습니다.

아마도 아닐 것입니다. 확실히, 이것은 도구 (실)의 엄청난 파단 변경을 필요로 할 것입니다. 보다 직접적이고 측정 가능한 이점이있는 덜 급진적 인 변화가 전달되었습니다.

나는 그것이 나쁜 생각이라고 말하는 것이 아니라 실용적인 생각이라고 생각하지 않는다는 것입니다.

나는 그것이 나쁜 생각이라고 말하는 것이 아니라 실용적인 생각이라고 생각하지 않는다는 것입니다.

나는 그것이 큰 질문처럼 보인다는 데 동의합니다. 하지만 제가 말하고자하는 것은 이것이 프로젝트의 중추적 인 문제처럼 보인다는 것입니다.

지금까지 Yarn은 개발자가 package.json 로 모든 프로젝트에 노드 종속성을 설치하기 위해 NPM 대신 사용할 수있는 도구 명시 적으로 선택해야합니다. 이는 엄청난 변화이며 우연히 만들어서는 안됩니다. 이것이 바로 전화를 걸기위한 위기 지점입니다.

제 생각에는 앞으로 3 가지 방법이 있습니다.

1. 모든 프로젝트 수준 인터페이스에서 Yarn과 NPM을 정렬하는 방법을 찾아 NPM의 드롭 인 교체를 계속합니다 (잠금 파일 표준화).
2. 명시 적으로 다른 프로젝트 수준 인터페이스 (예 : yarn.json 및 yarn.lock )를 사용하여 의도적으로 NPM에서 분기
3. NPMS 인터페이스의 절반, 반 다른 인터페이스를 제공하는 더블 다운. 이것은 실제로 포인트 2와 동일하지만 포인트 1과 같은 대부분의 사람들을 살펴보면서

여기서 세 번째 옵션은 전체 노드 공간을 혼동하고 두 도구를 상당히 약화 시킨다고 생각합니다.

여전히 역 호환이 가능합니다. Yarn은 npm lockfile 변환기를 내장 할 수 있으므로 package-lock.json을 볼 때 그대로 유지하고 메모리의 yarn.lock 형식으로 변환합니다. 내가 아는 한, Yarn의 잠금 파일이 npm보다 적은 정보를 가지고 있기 때문에 npm은 이것을 할 수 없으므로 제 생각에는 Yarn이 npm으로 표준화하는 것이 가장 좋습니다.

@nottrobin 나는 당신이 분석에서 대부분 정확하다고 생각합니다.

이제 지적했듯이 프로젝트는 Yarn과 NPM 중에서 명시 적으로 선택해야합니다. 이는 엄청난 변화이며 우연히 만들어서는 안됩니다.

나는 이것이 항상 사실이라고 생각하거나 적어도 Yarn이 처음에 선전 한 주요 이점 인 종속성 트리의 재현성이라고 생각합니다. yarn.lock 체크인 할 수 있지만 다른 개발자가 해당 잠금 파일을 고려하지 않고 종속성을 추가 / 제거하면 사실상 쓸모가 없습니다.

@nottrobin-@Vinnl에 동의합니다. 위에서 언급했듯이 다른 사람에게 작동 방식을 알리고 싶지는 않지만 동일한 프로젝트에서 종속성을 설치하기 위해 yarn과 npm을 모두 사용하는 것은 반 패턴이라고 생각합니다.

두 도구 모두이 작업을 수행하기 위해 기술적으로 많은 작업을 수행 할 수 있지만, 이것이 우리가 관리자로서 권장해야하는 것이라고 생각하지 않습니다. (다른 스레드의 다양한 토론이 보여 주듯이) 상호 교환 가능한 잠금 파일을 갖는 것에는 수많은 다른 이점이 있지만 개인적으로 이것이 그들 중 하나라고 생각하지 않습니다.

그러나 다른 개발자가 해당 잠금 파일을 존중하지 않고 종속성을 추가 / 제거하면 실제로 쓸모가 없습니다.

예, 저는 Yarn이 처음부터 그 진흙탕에 어느 정도 있었다고 생각합니다. yarn.lock 의 존재는 이미 부분적으로 자체 인터페이스가 있음을 의미했습니다. 나는 그것이 항상 약간 지저분한 일이라고 생각한다. Yarn의 목적은 사람들이 NPM에서 Yarn으로 이동하기를 바라는 목적에 부합했지만 돌아 오지는 않았습니다.

하지만 적어도 NPM이 여전히 전적으로 지원된다는 것을 알고 있었기 때문에 프로젝트를 더 편하게 내릴 수있는 결정이었습니다. 애초에 잠금 기능을 제공하지 않았기 때문에 항상 그랬던 것처럼 계속 작동 할 것입니다.

이제 NPM이 종속성을 잠그기 때문에 변경되었습니다. 내가 원사에 프로젝트를 결합하도록 선택하는 경우, 지금 유지됩니다 yarn.lock - - 날짜를, 그리고 package-lock.json 누군가가 효과적으로 NPM을 사용할 수 있습니다 더 이상 사실, 그래서 내 계획.

원사가 더 이상 npm의 드롭 인 대체품이 아니라는 말씀이신가요? 원사 만 사용하는 프로젝트에서만 사용해야한다는 거죠?

만약 그렇다면, 당신은 모든 사람에게 얀 홈페이지에이 사실을 분명히 밝혀야 할 빚이 있다고 생각합니다. 둘 다 사용하지 말고 이것 또는 npm을 사용하세요.

원사가 더 이상 npm의 드롭 인 대체품이 아니라는 말씀이신가요?

결코 그렇지 않았습니다. 인터페이스는 사용자가 사용 방법을 더 쉽게 이해할 수 있도록 npm을 다소 모방했지만 처음부터 일부 작업이 다르게 작동했습니다. 일부 사람들이 드롭 인 교체라고 생각한 주된 이유는 npm이 비교할 기능이 부족했기 때문입니다.

이제 npm이 어떤 측면을 따라 잡고 다른 방식으로 구현하기로 결정 했으므로 단순히 우리가 다른 접근 방식을 가지고 있고 다른 결정을 내리는 것을 보여주기 시작합니다 (예를 들어 최근에 구현 된 오프라인 미러 기능 npm이 기존 기능과 호환되지 않음). 간단히 말해서 "안전"한 것이 아니라 우연히 작동하게 된 것입니다.

만약 그렇다면, 당신은 모든 사람에게 얀 홈페이지에이 사실을 분명히 밝혀야 할 빚이 있다고 생각합니다. 둘 다 사용하지 말고 이것 또는 npm을 사용하세요.

사실 마이그레이션 지침이 있습니다. 귀하의 발언으로 인해 사람들에게 잘못된 인상을 줄 수 있는 잘못된 단락 이 포함되어 있음을 알게되었습니다 .🙁이 단락을 우리의 권장 사항에 따라 변경하는 PR을 기꺼이 받아 들일 것입니다 (예 : 팀간에 Yarn을 순서대로 일관되게 사용하는 것) 모든 사람이 프로젝트에서 사용할 수있는 다양한 기능의 혜택을 누릴 수 있도록합니다.

결코

오류 ... 마케팅 담당자와 얘기해야합니다. https://yarnpkg.com/lang/en/docs/

Yarn은 패키지 메타 데이터 형식을 포함하여 npm의 많은 기능과 직접 상호 운용되므로 손쉽게 마이그레이션 할 수 있습니다.

마케팅 담당자는 없지만 좋은 PR은 받아들입니다 🙃

이 특별한 경우에는 너무 잘못 들리지 않습니다. 우리는 모든 기능이 아닌 많은 기능과 상호 운용하며, 대부분의 경우 마이그레이션이 고통스럽지 않습니다 (더 나쁜 경우 yarn import 떨어져 있음).

마이그레이션은 고통이 없습니다

저는 마이그레이션에별로 관심이 없습니다. 나는 여기서 약속 한 것을 찾고 있습니다 (이 사람들은 _ 확실히 _ 마케팅 담당자가 있습니다) : https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

기존 워크 플로우와 동일한 기능 세트를 가지고 있으며 더 빠르고, 더 안전하고, 더 안정적으로 작동합니다.

오늘은 실이 아닙니다.

AFAICT 여기에는 4 가지 등급의 사용자가 있습니다.

• 프로젝트에서 원사 만 사용하는 사람들,
• facbook sales-pitch (위)를 구입했지만 아직 이러한 잠금 문제가 발생하지 않은 사람들,
• 필요할 때 잠금 파일을 수동으로 변환하거나 다른 해킹을 사용하여 비 호환성 문제를 해결하려고 애쓰는 사람들,
• 방금 원사를 포기하고 npm으로 다시 전환 한 것.

나는 정말로 마지막 카테고리에 있고 싶지 않지만 그것이 내가 밀려 오는 곳인 것 같습니다.

@Spongman 그 마지막 하나에서 당신을 막는 것은 무엇입니까? 우리는 아마 그것을 고칠 수 있습니다;)

@Spongman 저는 Yarn과 관련이 없기 때문에 좀 더 무뚝뚝하게 할 수 있다고 생각합니다. 문구가 잘못되었다고 생각되면 GitHub의 해당 페이지로 이동하여 수정 버튼을 클릭하고 더 나은 문구로 풀 요청을 제출하세요. arcanis는 그들이 그것에 대해 열려 있다는 것을 분명히했습니다.

(블로그 게시물을 편집 할 수 없을 것 같지만 여기에서 웹 사이트가 가장 중요 할 것입니다.)

@imsnif 와 @arcanis '의 답변에서 공식 입장은 Yarn이 NPM과 함께 계속해서 원활하게 작동하도록 "의도하지 않은"것으로 보입니다.

그러나 나는 이것이 Yarn이 준 인상이라는 @Spongman에 전적으로 동의하며 그 당시에는 그것이 사고라고 생각하지 않습니다. 그것은 그것의 천재였습니다. 공식 NPM 표준을 완전히 지원하면서 속도, 보안 등을 향상시킬 수있었습니다.

두 경우 모두,이 문제는 Yarn의 이전보다 훨씬 더 분명한 입장을 보여줍니다. 물론 Yarn의 관리자는 자신이 선택한 방향으로 선택할 수 있습니다.

그러나 나는 당신이 과소 추정 그들이 (프로젝트 레벨에서)은 NPM과의 호환성을 유지 믿고 정확하게 때문에 원사를 사용하는 사람의 수를 대폭라고 생각하고, 그렇지 않으면 스위치를하지 못했을 것입니다. 나는 https://github.com/yarnpkg/yarn/issues/3614 의 254 : +1 : s 및 10 : heart : s 와 57 개의 upvotes에 "" yarn.lock 및 package-lock.json을 커밋해야합니까? "라고

Yarn이 그 전면에 대한 책임을 포기하면 @Spongman 과 내 팀뿐만 아니라 다른 많은 팀을 잃을 것이라고 생각합니다.

솔직히 Yarn 만 사용하거나 npm 만 사용하는 문제를 이해하지 못합니다. 당신이 말하는 것은 기본적으로 "이봐, 우리 팀이 Yarn을 사용하도록 강요 할 수 없으므로 강제로 npm을 사용하도록 할 것"입니다. 그건 말이 안 돼. Yarn의 기능을 사용하는 경우 모든 사람이 Yarn을 사용하도록하고 npm 기능을 사용하려면 모든 사람이 npm을 사용하도록합니다. 이것만큼 간단합니다.

중간은 적어도 당신의 빌드가 팀 전체에서 일관성이 없다는 것을 의미하며, 이는 앞서 언급했듯이 Yarn의 전제에 위배됩니다. 엔지니어 중 한 명이 작업 공간을 사용하기 시작할 수 있으며 작동하지만 npm에서 중단됩니다. 오프라인 미러와 동일합니다. 종속성 해결도 동일합니다. 더 나쁜 것은 일부 필드가 npm에 의해 완전히 알려지지 않았기 때문에 조용히 잘못된 작업을 수행한다는 것입니다.

커뮤니케이션에 관해서는 fb 블로그 게시물에 드롭 인 교체에 대해 언급하지 않았습니다. Yarn이 소개 된 부분을 인용하겠습니다. 말 그대로 워크 플로우를 대체한다고 말합니다. 나는 당신이 "npm 레지스트리 와의 호환성 유지"에 대해 혼란스러워했다고 생각합니다. 이것은 우리가 아니라 npm에 가져와야 할 공정한 포인트입니다 (npm cli, npm 레지스트리, 그리고 물론 npm Inc 자체가 있습니다).

Yarn은 npm 레지스트리와의 호환성을 유지하면서 npm 클라이언트 또는 다른 패키지 관리자에 대한 기존 워크 플로를 대체하는 새로운 패키지 관리자입니다.

마지막 것에서 당신을 막는 것은 무엇입니까? 우리는 아마 그것을 고칠 수 있습니다;)

@zkat 도움이됩니다. 감사합니다.

@nottrobin- 나는 당시 주변에 없었기 때문에 원사의 원래 의도를 말할 수 없습니다. 그러나 나는 수십 개의 저장소가있는 혼합 원사 / npm 환경에서 작업하고있었습니다.

나는 그 당시 관련된 모든 개발자들에게 yarn / npm의 선택이 express / hapi, mobx / redux 등의 선택처럼 repo 당 선택이라는 것이 완벽하게 분명하다고 말할 수 있습니다. 이것은 npm으로 더욱 명확 해졌습니다.

개발자가 잘못된 도구를 사용하여 종속성을 설치하면 해당 종속성이 지속적으로 잠겨 있지 않기 때문에 npm @ 5 이전에도 엉망이됩니다. 그것은 우리의 다양한 환경에서 문제를 일으켰고, 이것이 실수라는 것을 모든 관련자들에게 매우 분명했습니다 *.

나는 이것이 혼란 스러울 수 있음을 알고 있습니다. 그리고 나는 이것이 자신의 잘못이 아니라고 모든 사람에게 100 % 명확하지 않을 수 있음을 이해합니다. 그러나 그 오해에 맞게 도구를 대폭 변경하는 것은 옳지 않다고 생각합니다. 내가보기에 yarn 은 박스 단위가 아닌 리포지토리 단위로 npm을 대체하는 드롭입니다.

* 근사 / npm 툴링이 혼합 된 여러 비 작업 공간 리포지토리의 특정 상황은 정확히 그러한 실수 가능성에 대한 기술 수준보다는 인간 수준에서 이상적이지 않았고 결국 수정되었습니다. 이 예제를 사용하여 올바르게 접근하면 두 도구가 나란히 작동 할 수 있음을 보여줍니다.

솔직히 Yarn 만 사용하거나 npm 만 사용하는 문제를 이해하지 못합니다.

예, @arcanis 와 @imsnif 가 이해하지 못한다는 점을 분명히했습니다. 내가 말하고자하는 유일한 요점은 많은 사람들 (: +1 : s 참조)이 동일한 "잘못"해석을하고 Yarn이 이해 여부에 관계없이 NPM과 함께 작동하기를 원한다는 것입니다. Yarn이 우리에게 도구가 아니라면 그렇게 될 것입니다.

(마지막 한 가지 요점- @imsnif Node 종속성을 설치하는 도구를 express vs hapi, mobx vs redux와 같은 프로젝트 선택과 비교하는 것은 완전히 어리석은 일입니다. 이는 앱의 기본 특성입니다. 명백한 차이점을 볼 수 없다면, 내 요점을 이해하지 못하는 것도 당연합니다.)

어쨌든 이제 끝났습니다. 나는 내가 할 수있는 한 나의 주장을 내린 것 같다.

오픈 소스 프로젝트의 경우 "팀"이 yarn 또는 npm을 사용하도록 강요하는 것은 결코 문제가되지 않습니다. 모든 사람에게 가장 편리한 것이 무엇인지에 대한 질문입니다. 현실 세계에서 npm은 왕이므로 실이 npm 세계에서 잘 작동하지 않으면 죽습니다.

^이

그것도 오해 인 것 같습니다. 지난 1 년 동안 Yarn은 npm 레지스트리에 대한 총 요청 량의 20 %에서 4 월 에

지금 당면한 주제로 돌아갈 수 있다면 감사하겠습니다. 즉, 설치시 package-lock.json 파일이 감지되면 경고를 작성하기 위해 PR을 작성하는 사람 은

Psst , https: //github.com/yarnpkg/yarn/pull/5920

굉장합니다 : heart_eyes :

이 작업과 yarn import 작업 사이에이 문제를 해결할 수 있습니까?

@jmorrell 이 이것이 Heroku의 문제에 어떤 영향을 미치는지에 대한 통계를 제공하여 이것이 충분한 지 또는 무언가를 변경 (경고 / 오류 등)하고 싶은지 결정할 수 있기를 기다릴 것이라고 생각했습니다.

편집 : afaik 경고가 아직 릴리스되지 않았으므로 아직 기다릴 시간이 있습니다.

그것도 오해 인 것 같습니다.

어떻게? npm의 트래픽 양은 프로젝트가 오픈 소스인지 여부를 알려주지 않습니다.

더 정확한 평가는 어떤 github 프로젝트에 (yarn.lock, package-lock.json) 0,1 또는 2가 있는지 계산하는 것입니다. 개인적으로 나는 yarn.lock 파일과 _no_ package-lock.json (명백한 것을 제외하고)이있는 github에서 오픈 소스 프로젝트 (눈에 띄는 크기)를 본 적이 없습니다.

IMO는 별도의 잠금 파일을 보관하려는 경우 두 패키지 관리자 모두 다른 사람의 잠금 파일과 ERROR (오버라이드 플래그 사용)를 감지해야합니다.

모두-주제에 집중하고 직접 관련이없는 댓글은 오프라인으로 처리해 주시기 바랍니다 (예 : Discord 채널). 많은 사람들이이 스레드를 구독하고 있으며 공정하게 npm <> yarn 토론이 여기에 속하지 않는다고 생각합니다. 감사!

나는 전체 트레드를 읽지 않았지만 IHMO 사용자는 최소한 모호성이 있다는 사실을 알려야합니다.

npm에 yarn.lock 파일이 표시되면 npm은 다음과 같이 인쇄해야합니다.
"경고 :이 프로젝트는 yarn을 사용하는 것 같습니다. 'npm install'대신 'yarn'을 사용해야합니다."

yarn이 package-lock.json 파일을 보면 yarn은 다음과 같이 인쇄해야합니다.
"경고 :이 프로젝트는 npm을 사용하는 것 같습니다. 'yarn'대신 'npm install'을 사용해야합니다."

그리고 위에서 제안한 것처럼 패키지 관리자 (package.json에서)를 "선호"하는 방법입니다.

나는 그 당시 관련된 모든 개발자들에게 yarn / npm의 선택이 express / hapi, mobx / redux 등의 선택과 마찬가지로 리포지토리 별 선택이라는 것이 완벽하게 분명하다고 말할 수 있습니다.

이것은 나에게 전혀 명확하지 않았습니다. 지금까지 나는 이것이 개발자 로컬 선택이라고 생각했고, 여러 개발자가 자신이 좋아하는 것을 사용하여 단일 저장소에서 공존 할 수 있었지만, 하나만 일관되게 사용하는 것이 _ 조금 더 편리했습니다 _. Express / hapi 등의 예는 좋지만 이것이 선택이 아님을 분명히합니다. 이것은 더 많은 가시성을 가져야합니다.

package.json에 필드를 추가하여 프로젝트에서 사용해야하는 패키지 관리자를 나타냅니다.

"package-manager": "yarn"

모든 패키지 관리자에서 구현되는 경우 이것이 최상의 솔루션이라고 생각합니다.

그런 다음 패키지 관리자는 redux가 필요하지만 mobx 함수를 호출하려고 시도한 경우 오류가 발생할 것으로 예상하는 것처럼 잘못된 프로젝트에서 호출되면 진행을 100 % 거부해야합니다. 경고가 아닌 오류를 발행하고 올바른 패키지 관리자로 진행하는 방법을 사용자에게 알려야합니다.

package.json에 필드를 추가하여 프로젝트에서 사용해야하는 패키지 관리자를 나타냅니다.
"package-manager": "yarn"

모든 패키지 관리자에서 구현되는 경우 이것이 최상의 솔루션이라고 생각합니다.

npm이 이것을 고려하기를 원한다면 적절한 장소에서 토론

새로운 "패키지 관리자"필드에 대해 권장하고 대신 이미 선행 기술이있는 기존 engines 스탠자를 권장합니다.

yarn 및 npm 문서는 모두 engines.npm 및 engines.yarn 사용을 언급하여 각각의 버전을 지정합니다. 원사 버전이 engines.yarn 충족하지 않는 경우에도 원사 오류가 발생합니다.

https://yarnpkg.com/en/docs/package-json#engines-
https://docs.npmjs.com/files/package.json#engines

npm이나 yarn이 "경쟁하는"관리자에 대해 engines 를 확인하지 않더라도 (좋을 것입니다),이 필드를 사용하여 관리자가 사용될 것으로 예상되는 다른 개발자와 통신 할 수있는 좋은 방법입니다. (package-lock.json 또는 yarn.lock의 존재가 실마리가 충분하지 않은 경우)

분기가 아닌 패키지 관리자 간의 수렴을보고 싶습니다.

동의합니다. 수렴 또는 거부입니다.

그러나 현재의 모호하고 잘못된 중간 지점은 해 롭습니다.

나는 여전히 다른 사람들의 잠금 파일이있는 상태에서 오류를 던지는 것만으로도 기존 프로젝트에 대한 마찰을 최소화 할 것이라고 생각합니다.

npm이 이것을 고려하기를 원한다면 적절한 장소에서 토론을 여는 것이 좋습니다.

감사합니다. 방금 가입했습니다. 이 방향으로 최근 스레드가 있습니다 : https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

내 투표는 경고 대신 전체 중지 오류를 표시하는 것이므로 해당 스레드에 새 시작 스레드를 추가해야하는지 확실하지 않습니다.

분기가 아닌 패키지 관리자 간의 수렴을보고 싶습니다.

여기도 마찬가지입니다. 지금은 호환되지 않지만이 차이는 이미 발생했으며 이미 많은 사용자와 프로젝트에 마찰을 일으키고 있습니다.

팀 간의 추가 대화에서 나오는 융합이 무엇이든 시간이 걸립니다. 도착하면 제안 된 오류를 제거 할 수 있으며 사용자는 간단하게 패키지 관리자를 전환하고 혼합 할 수 있습니다.

이제 오류를 추가하면 더 많은 혼란을 피할 수 있으며 수렴 방향으로의 노력이 중단되지 않습니다.

새로운 "패키지 관리자"필드에 대해 추천하고 대신 이미 선행 기술이있는 기존 엔진 스탠자를 추천합니다.

합리적으로 들립니다. 호환되지 않는 패키지 관리자의 존재를 감지하는 특정 방법에 집착하지 않습니다.

그림을 추가하기 위해 특히 사용 사례는 gatsbyjs입니다. 상황은 @gaearon이 보고 한 습니다 .

React App 사용자를 만들려면 프로젝트가 Yarn으로 생성되지만 (Yarn이 시스템에있는 경우) 일부 라이브러리의 문서를 따라 npm 설치를 지시하고 전체 트리를 날려 버리기 때문에 이것은 매우 혼란 스럽습니다.

이 문제를 방지하기 위해 gatsby는 yarn을 사용하지만 기본 스타터에 package-lock.json 도 추가합니다. 그러나 사용자는 두 잠금 파일을 모두 사용하고 경고를보기 시작합니다. 그중 하나를 삭제하는 것은 쉽지만 온 보딩 경험을 혼란스럽게 만듭니다.

귀하의 의견에 감사드립니다.

@jmorrell - https: //github.com/yarnpkg/yarn/pull/5920 은 7 월 25 일 1.9.2 에 출시되었습니다. 모두가 업그레이드되었습니다)-하지만 그 이후로 Heroku의 이중 잠금 파일 오류와 관련하여 공유 할 통찰력이 있습니까?

@imsnif 이메일 알림에 감사드립니다! 여기에 업데이트를 놓쳐서 죄송합니다.

다음은 2018 년에 매주 이러한 특정 실패를 경험 한 앱 수의 그래프입니다.

(나는 y 척도를 편집했지만 이것은 100 명의 개발자를 나타내고 추세를 보여줍니다)

1. 7 월의 하락은 S3의 관련없는 문제에서 비롯됩니다.

2. 7 월 25 일 이후의 추세를 살펴보면이 경고는이 오류를 경험하는 사람들의 수에 상당한 영향을 미쳤습니다. 나는 변화의 규모에 다소 놀랐다.

@jmorrell- 이것은 정말 대단합니다!
나도 이것에 상당히 놀랐다는 것을 인정할 것이다.

나는 (실 측에서)이 문제가 해결되었다고 생각할 수 있다고 생각합니다. 동의하십니까?

나는 여전히 오류를 수정하기 위해 package-lock.json 를 제거하라는 조언이 오해의 소지가 있다고 생각합니다. 이것은 일반적으로 다른 패키지 버전 세트를 사용하게되며 (다시 일반적으로) 비 호환성과 파손으로 이어질 것입니다. 또한이 조언은 프로젝트에서 사용하는 패키지 관리자를 결정하는 사람들에게만 유용합니다. 이 조언을 따르는 일반 기여자도 문제에 직면하게 될 것입니다.

package-lock.json 가 있고 yarn 가 설치하는 버전이 npm 가 설치할 버전과 동일하다는 것을 보장 할 수없는 경우 IMO는 오류와 함께 실패 합니다 .

@Spongman을 입력 해 주셔서 다시 한 번 감사드립니다. 이 모든 것이 우리 위에있는 (매우 긴) 스레드에서 잘 논의되었다고 생각하며 다시 시작하는 것이 합리적이지 않다고 생각합니다. 우리 모두 당신의 입장을 이해한다고 생각합니다. 참여해 주셔서 감사합니다.

@jmorrell 이 다음 주 정도에 저에게 달리

@imsnif 지금까지 9 월 (9 월 1 일-9 월 20 일)의 실패를 다른 경로로 살펴

나는 이것에 대해 npm에서 어떤 움직임도 보지 못했기 때문에 거기에 경고를 추가하는 PR을 만들고 수락되는 것을 볼 것입니다.

나는 (실 측에서)이 문제가 해결되었다고 생각할 수 있다고 생각합니다. 동의하십니까?

나는 이것이 사용자를 위해 해결되었다고 생각하지 않으며 사용자 경험은 여전히 ​​좋지 않습니다. 그러나 npm이이 케이스를 치는 사용자에게 피드백을 제공하면 숫자가 어떻게 변하는 지 볼 수 있습니다.

이 항목을 닫거나 추가 변경을 원하는지 여부는 귀하에게 맡기겠습니다. 이것이 여전히 사용자에게 큰 문제라면 몇 달 안에 새로운 문제를 열게되어 기쁩니다.

@jmorrell- 이 문제가 많은 관심을 끌고 대화가 계속 다시 시작되고 심지어 반복되는 것을 보면 우리가 가지고있는 정보로 지금 종료하는 것이 더 나을 것이라고 생각합니다.

npm도 경고를 제공하는 경우에도 여전히 문제가 발생하면 오류 토론을 다시 시작하거나 다른 솔루션을 살펴볼 것입니다. 이 경우 개인적으로 핑을 해주세요.

이 문제를 제기하고 기여하고 모든 변경 사항을 적용 해 주셔서 감사합니다! 저는 개인적으로 이번 호 이후에 실이 더 좋다고 느낍니다.