Yarn: package.json에 저장하지 않고 패키지 추가

아니요,이 기능은 의도적으로 생략되었습니다. package.json에 반영되지 않고 패키지를 설치하는 것은 위험한 것으로 간주됩니다. 왜 그런 것이 존재하기를 원합니까?

Facebook 발표에서

npm 설치의 "보이지 않는 종속성"동작을 제거했습니다.명령을 분할하십시오. yarn add <name> 실행은 npm install --save <name> 실행과 동일합니다.

나는 그 기능을 테스트하기 위해 꽤 자주 사용했습니다. 특히 내가 유지 관리하는 라이브러리로 작업 할 때 릴리스를 만들기 전에 변경 사항을 테스트하기 위해 로컬 버전 ( file: dep 생성)을 설치해야합니다.

npm의 구현이 기본적으로 좋지 않은 선택이라는 데 동의하지만 명시 적으로 사용할 때 유용 할 수 있다고 생각합니다.

네, 명시 적 플래그와 함께 할 수 있도록 허용하는 것이 좋을 것이라고 생각합니다. 현재로서는 여전히 npm i =) 사용할 수 있지만 npm 필요를 제거하기 위해서입니다.

이에 필수적 변화의로 우리는 명시 적으로이 기능을 지원하지 않습니다 node_module 이후로 닦아 것 yarn install 우리가 고려 이후의 package.json 및 yarn.lock 될 수 진실의 근원.

Windows (libxslt)에 쉽게 설치할 수없는 종속성이 있으므로 다음과 같습니다.

• Windows의 경우 : 개발자는 node_modues에서 압축을 풉니 다.
• Linux의 경우 : 개발자가 저장하지 않고 설치합니다 (package.json에있는 경우 빌드가 실패하므로 Windows를 사용하는 개발자는 설치를 수행 할 수 없습니다)

원사를 사용하여 깨끗한 방법이 있습니까 (또는이 결과를 얻는 더 좋은 방법)?

(패키지가 package.json에 반영되어야한다는 데 동의하지만 여기에서는 깨끗한 솔루션을 찾을 수 없습니다)

@GuillaumeLeclerc yarn add -D xxx 는 어떻습니까? package.json에서 항목을 직접 제거합니까?

다음에 다른 패키지를 추가 할 때 제거됩니까? 그렇지 않습니까?

@GuillaumeLeclerc 불행히도 그렇습니다.

@GuillaumeLeclerc 댓글을 정리하고 싶을 수도 있습니다 ...

package.json 또는 yarn.lock을 변경하지 않고 모듈을 설치할 수 있도록 yarn add --no-save 와 같은 인수를 추가하십시오. 나는 종종 모듈을 커밋하기 전에 테스트해야한다는 것을 알게됩니다.

"최대 호출 스택 크기를 초과했습니다."라는 메시지가 표시되어 일반 npm install 사용할 수 없습니다. 따라서 실은 설치하는 유일한 실행 가능한 방법입니다.

변경 사항을 package.json yarn.lock으로 되 돌리지 마십시오!

나를 위해 이것은 peerDep을 설치하려고하기 때문에 나를 물고 있습니다. Yarn은 install 동안 피어 deps를 설치할 방법이 없으므로 수동으로 수행해야합니다. package.json / yarn.lock에 추가하지 않으면 yarn add <package> 할 수 없습니다. 막혔어요.

@viveleroi 이것은 완전히 정확하게 들립니다. package.json 추가하지 않고 피어 종속성을 설치하려는 이유는 무엇입니까?

이 복제 때문에 @hpurmann 내 peerDependencies 에 dependencies (또는 devDependencies 내가 사용하는 경우 --dev ). 그것이 의도 된 것이라면 확실히 직관적이지 않습니다.

@hpurmann 반응 구성 요소를 공개하고 싶으므로 react은 peerDep이어야합니다. 하지만 개발을 위해 리 액트를 프로젝트에 설치해야합니다.

--no-save => 추가하면 매우 중요합니다.
특정 패키지에 대한 특정 선택적 종속성을 건너 뛰어야합니다. 나는 당신의 실로 그것을 할 수 없습니다. --no-save 옵션과 함께있을 수 있습니다.

yarn link local-pkg 는 호스트 앱에 local-pkg의 종속성을 설치하지 않기 때문에 직접 설치하고 싶지만 게시되면 local-pkg에서 가져 오므로 app package.json에 저장하지 않습니다. .

나는 소유자가 이것에 대해 그렇게 의견이있는 이유를 이해하지 못한다. 사용법이 보이지 않는다고해서 아무것도 없다는 의미는 아닙니다. 나는 사람들이 그것을 요구한다면 그것은 그들이 그것을 필요로한다는 것을 의미하고 그들은 반드시 어리석은 것이 아니라고 믿습니다.
선택적 --no-save 옵션을 추가하면 일부 사람들의 문제가 해결되고 전혀 문제가 발생하지 않습니다.

AWS Lambda에서 실행되는 NodeJS 프로젝트에 Yarn을 사용하려고합니다. 이 기능이 지원되지 않는 이유에 놀랐습니다. 내 사용 사례는 로컬 개발 환경에 aws-sdk를 설치해야하지만 AWS Lambda가 이미 해당 환경에 설치되어 있으므로 package.json 저장하고 싶지 않습니다. aws-sdk를 포함하면 최종 패키지가 비대해질 것입니다.

원사 링크와 원사 추가는 함께 살 수 없습니다. yarn add는 package.json에 의존하는 반면 yarn link는 로컬 패키지를 다른 위치로 연결합니다.

Y에 의존하는 패키지 X를 개발하고 있다고 가정 해 보겠습니다. 여러분은 X와 Y의 개발자이므로 X와 Y를 로컬로 유지하고 Y를 X의 디렉토리에 연결합니다. Y에 대한 링크.

이 문제를 어떻게 해결합니까?

~이 경우 npm-commands를 사용하여 json 또는 yarn.lock 패키지에 풋 프린트를 만들지 않고 간단히 설치할 수 있습니다.

~ npm install [packages ...] --no-save --no-package-lock ~

@heikomat이 아래에 언급했듯이 npm5는 설치 후 자동 정리를 사용하기 때문에 (https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921 참조) 이것은 다음과 같습니다. 옵션이 아니며 node_modules-folder를 완전히 깨뜨릴 수 있습니다.

그래 이제 npm 없이는 살 수 없어

기본 node_modules에 로컬 하위 모듈의 종속성을 설치하는 스크립트 중 하나에서 npm install 을 사용했습니다. 이것은 npm4에서 잘 작동하지만 npm5가 설치 중에 일부 패키지를 핵으로 결정하기 때문에 npm5에서는 완전히 손상되었습니다 -.- (https://github.com/npm/npm/pull/18921 참조)

그런 이유로 나는 내 스크립트의 npm install 를 yarn으로 바꾸려고했지만, yarn이 설치하는 동안 항상 로컬 하위 모듈의 package.jsons를 건 드리면 실제로 그렇게 할 수 없습니다. 내 스크립트가 조용히 지저분 해지고 실 후 "정리"됩니다.

이미 --no-lockfile 옵션이 있으므로 node_modules 폴더를 생각할 수 없습니다.
그러나 개발자는 package.json을 변경 불가능하게 유지하기위한 해결 방법이 여전히 필요합니다.

감사합니다.

누군가가 모듈 설치에 대한 독특한 사용 사례를 설명하지만 기록하지 않을 때마다 관리자가 다시 와서 시보레를 암송하는 방식이 마음에 듭니다. 도덕적 실패로 고통받는 사람들로부터 오는 것과 같은 많은 다른 사람들의 요청을 받아 들일 수 있다면 당신의 고집에 대한 자신감을 쉽게 느낄 수 있어야합니다. 절충안으로 스위치 이름을 --i-am-a-heritic-and-a-bad-programmer ?

yarn 가 npm 에서 보존하는 한 가지 주요 결함을 보면 안타깝게도 조직 외부의 모든 사람에 대한 적대감이 있습니다.

그리고 제 경우에는 # 4297 문제에 대한 해결 방법으로 사용하고 싶었습니다. :)
개발자가 일을하도록 인위적으로 제한하면 특정 상황에서 제품을 사용할 수 없게 될 수 있습니다.

장난 해? 이것은 희화입니다. 모든 개발자 워크 플로가 어떻게 작동해야하는지 지시하지 마세요. 이것이 바로 NPM이 우리에게 적합하지 않은 이유이며 우리는 Yarn으로 옮겼습니다. "package.json과 yarn.lock은 진실의 근원이어야한다"는 이념은 말도 안됩니다. 패키지는 소스 코드를 수정하지 않고 설치할 수 있어야합니다. 그렇게 간단합니다.

어서, 관리자. 커뮤니티에서이를 실제로 필요로하는 것은 분명합니다. 필터링되지 않고 잘못 배치 된 철학으로 지적인 대화를 중단하지 마십시오.

지금은 찾는 yarn 내가 테스트 할 필요가 어디 모듈을 가지고 있기 때문에 휴식 시간 내 테스트를 require 내가로 예를 들어 모듈 커밋이 필요하고 순서대로 시험에를 ./node_modules . Yarn은 yarn install 실행할 때 예제 모듈을 삭제합니다. 나는 더 많은 "진실의 근원"pedantry를 생각한다.

사용 사례 : 내가 사용하는 도구에는 패키지가 필요합니다. 팀은이 도구를 사용하지 않습니다. 팀 (당연히)은 해당 패키지가 설치되는 것을 원하지 않습니다.

이것은 앵귤러 스타일 가이드에 codelyzer를 사용하는 것이 매우 실망 스럽지만 나머지 팀은 코드 기능에 영향을 미치지 않습니다. 지금 작동하도록하는 유일한 방법은 실 자물쇠에 추가하고 실 자물쇠가 실제로 변경되지 않았다고 가정하거나 팀이 실을 사용하더라도 npm을 사용하는 것입니다. 둘 다 끔찍한 옵션입니다.

이미 2018 년이지만 유효한 수많은 사용 사례에도 불구하고이 기능은 아직 추가되지 않았습니다.

이것이 왜 유용한 지 또 다른 예를 들자면 :

새 버전을 설치하고 테스트를 실행 한 다음 package.json / *.lock 하고 해당 변경 사항을 커밋하거나 오류가 발생한 경우 롤백하여 종속성을 자동으로 업데이트하는 스크립트가 있습니다. 이전 버전을 기억하고 다시 명시 적으로 adding 를 기억하는 대신 yarn 다시 실행하는 것이 더 쉽습니다.

또한 테스트를 중단하지 않고이 종속성을 실제로 업데이트 할 수 있는지 "절대적으로"확인하기 전에 단일 진실 지점 ( package.json )을 변경하지 않는 것이 더 깔끔합니다. 지금은 코드를 깨는 종속성이 포함 된 package.json (임시적 일지라도)로 끝납니다.

이 문제에 대한 유효한 사용 사례가 많이 있습니다. yarnpkg 메인테이너는 PR이 생성된다면 기꺼이 받아 들일까요?

아직이 프로젝트에 참여하고 있다면 @kittens를 핑합니다 ...

그동안 package.json 의 scripts 섹션에서 다음 스크립트를 사용합니다.

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

원사에 대한 대안이 있다고 생각합니까?

대안이 없습니다. npm5는 내 인생처럼 지저분합니다.

.bin 폴더에 심볼릭 링크를 복사하는 것을 잊지 마십시오. ;)

나에게는 chmod 444 package.json 및 yarn add XXXX --no-lockfile 적어도 로컬 개발 및 테스트 문제를 해결합니다.
추가는 (예상 된) 권한 오류로 끝나지만 추가 된 모듈은 나중에 node_modules에 존재하며 로컬에 설치된 피어 종속성으로 테스트 할 수 있지만 package.json에는 유지되지 않지만 피어 종속성으로 유지됩니다.

때때로 why-is-node-running 와 같은 디버깅 라이브러리가 일시적으로 필요합니다. 한 번만 사용하면 제거하고 싶을 것이고 --no-save 옵션을 사용하면 종속성을 오염시킬 위험없이 설치하고 잊을 수 있습니다.

저는 Lerna를 사용하고 있으며 프로젝트가 이미 이전 단계에서 빌드되고 아티팩트가 전달되었으므로 게시 단계를 위해 CI 단계 중 하나에 _only_ Lerna를 설치하고 싶습니다. 이것이 유효한 시나리오입니까?

이 기능을 사용할 수 있다면 몇 단계를 절약 할 수 있습니다.
내 node_modules 은 어쨌든 .gitignore에 있습니다.

대신에:

git clone external-package (needed for temp testing only)
yarn install
yarn link

내 원래 저장소로 돌아 가기
yarn link external-package

다만:
원본 저장소 :
yarn install external-package --no-save

빌드 파이프 라인의 일부로 nsp를 설치하고 실행하여 dependency-check.xml을 내 보내야합니다.

이 간단한 도구 설치가 패키지 목록에 반영되어야하는 이유를 알 수 없습니다. 태그를 푸시하기 전에 수정을 취소하기 위해 git checkout ${BRANCH_NAME} 를 수행해야 함을 의미합니다.

나는 소스를 수정하려는 것이 아닙니다. 나는 원하지 않으며 그것은 내 사업이 아닙니다. 그것은 내 조직의 개발 팀에 달려 있습니다. 추상적 인 철학 때문에 제 삶을 조금 더 어렵게 만들고 계십니다. 멈춰.

이 문제가 종결 된 이유는 무엇입니까? --no-save 스위치가 PR에 추가 되었습니까?

종속성에서 가져온 모듈의 버전을 변경하고 싶을 때가 있습니다. 예를 들어, 다른 개발 의존성에 의해 가져온 @types/sinon 는 최근에 내 tsc를 깨뜨 렸습니다. 내 dev 종속성에 @types/sinon 을 (를) 원하지 않지만 계속 작업 할 수 있도록 yarn add @types/[email protected] --no-save 버전을 수동으로 변경하고 싶습니다. 대신 npm으로 다시 전환합니다. 매우 실망 스럽습니다.

플랫폼 별 바이너리 자체를 해킹하는 프로덕션 전용 종속성 (앱 역학)이 있습니다. 개발 머신에서는 필요하지 않습니다. yarn add ... --no-save 추가하면 package.json을 위험에 빠뜨리는 스크립트없이 깔끔하게 배포 할 수 있습니다 (특히 package.json은 각 스크립트 나 종속성의 목적을 설명하는 주석을 가질 수 없기 때문에).

cc @kittens @hpurmann

이 매우 인기있는 문제를 해결하거나 해결 된대로 잠그십시오. 위에서 제기 된 모든 비판에 대해 구체적인 답변을 주시면 감사하겠습니다.

그리고 커뮤니티는이 기능을 제공 할 준비가되어 있습니다. 이러한 풀 요청을 수락 할 것인지 알려주십시오. 감사합니다.

하하, 아직 구현되지 않음, niiiiice

왜 그런 것이 존재하기를 원합니까?

사람들이 JSX에 대해 처음에 템플릿과 로직을 혼합했을 때 말했던 것과 똑 같았습니다. 가능하고 사용 사례가 있다면 올바른 질문은 왜 안 되는가? 나는 그것이 플래그라는 것을 의미하며 기본 동작이 아니므로 yarn에게 명시 적으로 말하고 있습니다.

트윗 담아 가기
반응을 기반으로 여러 패키지가 있으며 이들은 서로에 대한 하위 모듈 종속성이 있습니다. 그래서 저는 react 및 react-dom을 peer-dep로 사용했지만 이러한 패키지를 개별적으로 빌드해야 할 때 react 및 react-dom이 필요합니다.
나는 이것이 패키지를 dep로 추가하지 않고 로컬로 설치하는 데 적합한 사용 사례라고 생각합니다.
내 프로젝트에서 그렇게 사소한 용도로 npm을 사용하고 싶지 않습니다.
--no-save 와 유사한 것을 기다리는 모든 업데이트.
개발자가 부작용을 알고 있다고 가정하면 커뮤니티가 요구하면 기능을 추가하는 데 아무런 해가없는 것 같습니다 (얀 설치를 실행하자마자 로컬 패키지가 손실 됨).
감사

편리한 트릭은 yarn add --dev pkg && yarn remove pkg 입니다. 같은 일을합니다. 잠금 파일은 이전과 동일하게 유지되므로 그대로 유지됩니다.

이것은 @Legends가 이전에 언급했지만 강조 할 가치가 있습니다.

일부 경우에 대한 한 가지 해결 방법은 별도의 폴더에 필요한 패키지를 설치하고 그렇지 않으면 추가되었을 위치에 필요한 패키지를 yarn link 하는 것입니다. 이상적이지는 않지만 도움이 될 수 있습니다.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb 확실히 가치가 없습니다, imho. add + remove 는 npm에서 --no-save 되는 작업입니다. 시스템 링크를 엉망으로 만들지 않으며 잠금 파일을 나쁜 방식으로 건드리지 않습니다. 즉, yarn remove 이후에도 동일합니다.
프로그래밍 방식으로 그 일을하고 싶다면 확실히 dirs, linking 등을 만드는 것은 갈 길이 아닙니다.

어떤 경우

예를 들어? 확실히 이상한 것들은?

트윗 담아 가기

그렇다면 피어 종속성이있는 패키지를 개발하는 데 권장되는 방법은 무엇입니까?

예를 들어 React가 내 패키지에 peerDependency로있는 경우 가져 오기를 해결하려면 devDependency로 추가해야합니까?

https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json을 보면 대답은 '예'라고 생각합니다.

@ 18steps 확인 https://www.npmjs.com/install-peers

이 기능을 사용하는 몇 가지 상황이 있습니다.

CI 라이프 사이클에서와 마찬가지로 커버리지 리포터를 추가했습니다. 하지만 package.json 로 가져올 수 없으며 NPM 게시에 영향을 미칩니다.

저장하거나 저장하지 않을 경우이 선택은 도구가 아닌 개발자 자신에게 달려 있습니다.

자, 이것을 유지 관리자의 관점에서 살펴 보겠습니다. 순진한 --no-save 솔루션의 단점을 확실히 볼 수 있습니다. 우리는 여기서 아주 철저한 설명을 얻지 못했지만 강철 남자를 만들려고 노력할 것입니다. 그들이 나를 바로 잡을 수있을 것입니다. 아마도 우리는 타협을 찾을 수있을 것입니다. 트윗 담아 가기

(죄송합니다. 의도 한 것보다 오래되었습니다.)

최신 노드 및 웹 애플리케이션에 대한 종속성 관리는 약간 혼란 스럽습니다. 그러나 우리는 중복 제거 및 재현 가능한 빌드와 같은 기능을 통해 안정적인 자동화와 일정 수준의 제어 및 예측 가능성을 모두 제공하는 시스템을 원합니다.

복잡성을 파악하려면 무엇이 설치되어 있고 왜 설치되었는지 알아야하며 불일치를 해결하기위한 단일 소스가 필요합니다. 명백한 것을 말할 위험이 있지만 node_modules 자체는 이러한 역할 중 하나를 수행 할 수 없습니다. 트래버스하기에는 너무 느리고, 전송하기에는 너무 크고, 버전 제어에 너무 세밀하며, '왜'측면을 인코딩 할 수 없습니다. 이것이 우리가 package.json 및 yarn.lock 있는 이유입니다.

Yarn은 인터페이스를 통해 제한된 액세스를 제공하여 node_modules 의 복잡성을 캡슐화합니다. 캡슐화를 중단하지 않겠다고 약속하면 중복 제거 및 재현 가능한 빌드와 같은 특정 보증을 받게됩니다. package.json 및 yarn.lock 해당하는 변경없이 node_modules 을 설치하면 해당 보증을 잃게됩니다.

게다가 이것은 많은 개발자들이 명시 적으로 인식하지 못하는 무언의 계약입니다. 그들이 그것을 깨뜨릴 때 그들은 고의적으로 그렇게하지 않습니다. 따라서 일이 잘못되면 Yarn이 부당하게 비난받을 수 있습니다. 또한 발로 쏘기 어려운 도구를 만드는 것은 나쁜 디자인 철학이 아닙니다.

그러나 타협해야하는 몇 가지 이유를 볼 수 있습니다.

• 여기에 분명한 필요가있는 것 같습니다. 위의 주석에 나열된 많은 사용 사례와 '좋아요'/ '싫어요'비율을 살펴보세요. 이러한 일방적 인 반응에 직면 한 관리자의 명백한 고집은 Yarn을 너무 좋아 보이게하지 않습니다.

• 모두에게 효과가있을 수있는 해결책이 있습니다. 예를 들어, 새 파일 yarn.local.lock . 개발자는이를 .gitignore 에 넣고 --no-save 플래그와 해당 종속성으로 설치된 모든 패키지의 기록을 유지합니다.

  yarn.lock 을 이로부터 격리하기 위해 '로컬'종속성 트리의 중복 제거 및 평면화가 제한됩니다. 로컬 잠금 파일은 기본 잠금 파일의 버전과 일치하도록 조정될 수 있지만 (이 경우 중복 제거) 그 반대는 아닙니다. 결과적으로 많은 전 이적 로컬 종속성이 node_modules 로 평면화되지 않을 수 있습니다.

  이 솔루션을 통해 Yarn은 모든 패키지를 계속 추적 할 수 있으며 개발자는 저장소를 오염시키지 않고 항목을 설치할 수 있으며 재현 가능한 빌드를 보존 할 수 있습니다. ( devDependencies 섹션이있는 package.local.json 공간도 있지만 필수 항목인지는 모르겠습니다.)

• 사람들은 이미 원하는 것을 얻기 위해 이미 해결 방법을 사용하고 있습니다. 그 중 적어도 세 가지는 위의 주석에 설명되어 있습니다. 그러나 그들은 사용하기가 불편하고 동일한 보증을 제공하지 않으며 개발자가 Yarn과 싸워서 알아낼 것을 요구합니다. 두 세계 모두 최악입니다.

뭔가 놓쳤을 수도 있지만 이건 가치있는 대화 인 것 같습니다.

또 다른 사용 사례가 있습니다. REPL에서 모듈을 사용할 수 있기를 원하지만 내 코드에서 사용할 의도는 없습니다. 현재로서는 다른 폴더로 이동하여 해당 모듈을 설치 한 다음 ../other-project/data/xyz.json 사용하여 일부 json 파일을 가져와야합니다.

하지만 내가 모듈을 가져오고 싶고 그게 상대 경로를 사용하여 다른 모듈을 가져 오면 깨질 것입니다.

저장하지 않고 node_modules 모듈을 설치하면 훨씬 쉽게 할 수 있습니다.

나는 관리자들이이 아이디어에 얼마나 저항하는지 놀랐다.

맙소사, 방금 이전 의견을 읽었으며 유지 보수의 태도가 실망 스럽습니다. 프레임 워크 라이브러리에 대한 종속성이있는 많은 프레임 워크 특정 플러그인을 개발하고 이러한 플러그인을 하드 종속성으로 추가하는 것을 피하고 싶습니다.

peerDependencies 정의 된 특정 패키지에 의존하는 플러그인이 있습니다. 이제 다른 많은 사람들이 이미 언급 한 것처럼 문제는 package.json 종속성을 추가하지 않고 로컬로 설치하는 방법입니다. 파일? 글쎄, 당신은 할 수 없습니다.

내가 찾은 유일한 해결책은 peerDepencies 를 devDependencies 하는 것입니다. 이것은 전혀 이상적이라고 생각하지 않지만 문제를 해결합니다. 끔찍한 상태의 npm 은 package.json 파일을 수정하지 않고 설치됩니다.

트윗 담아 가기

커뮤니티에 대한 응답을 포기 했습니까? 분명히이 문제를 무시하는 것은 당신에게 호의를 베푸는 것이 아니며 사라지지 않습니다. 누군가가 작업을하고 PR을 제출하는지에 대한 간단한 질문에 대답하지 않을 경우 이것을 오픈 소스 프로젝트라고 부르는 것이 무슨 소용이 있습니까?

나는 아마도 @viveleroi가 그의 아주 유효한 사용 사례를 설명한 직후에 했어야 했다. 그 당시 나는 그의 대답을 엄지 손가락으로 치켜 세웠는데, 그것은 분명히 주목 받기에 충분하지 않았습니다.

나는 마음을 바꿨다. 일반적으로 사람들은 많은 것을 원하고 유지 관리자가 모든 기능을 수용하면 소프트웨어가 부풀어 오릅니다. 이 유스 케이스는 없지만 많은 사람들이 원합니다.

나는 아무것도 결정할 수 없다. 저는이 프로젝트의 관리자가 아닙니다.

@Vheissu yarn add --peer <dep> 의 문제는 무엇입니까?

나를 위해 원사 추가-피어다른 패키지를 추가 할 때까지 작동합니다.이 시점에서 기존 피어 dep가 로컬 설치에서 제거되고 수동으로 읽어야합니다.

오늘은 express를 사용하여 라이브러리의 예제 구현을 작성하고 있지만 내 코드는 express에 직접 의존하지 않기 때문에이 기능을 원합니다. Express를 설치하거나 의존하는 것을 원하지 않지만 현재 디렉토리에 설치하고 싶습니다.

@ brendan-hurley @suyanhanx 처럼 로컬이 아닌 CI에 설치하려는 종속성이 있습니다.
로컬 종속성을 최소한으로 유지하여 node_modules 을 (를) 부풀려서 프로젝트에서 작업하는 모든 개발자에게 시간과 공간을 낭비하지 않도록하고 싶습니다.

CI에는 필요하지만 로컬이 아닌 패키지 :

• CI 특정 도구 : 시맨틱 릴리스, 그린 키퍼 잠금 파일
• 커버리지보고 도구 : codacy-coverage, 작업복
• CI 용 테스트보고 도구 : jest-junit 등

이 기능이 필요한 이유는 다음과 같습니다.

yarn link 를 사용하면 패키지의 종속성이 연결되지 않으므로 다음 위치에 설치해야합니다.
연결된 대상-이러한 외부 종속성을 package.json 에 추가하면 너무 불편합니다.

yarn link 는 종속성을 추가하거나 대상 package.json 에서 제외하는 방법을 제공해야합니다.

꽤 난해한 사용 사례가 있지만 이것은 나에게 도움이 될 것입니다. yarn.lock 및 package.json 이 (가) 진실의 원천이되는 것이 왜 중요한지, 그리고 --no-save 명령을 사용하면 변경 사항이 후속 yarn 에서 지워진다는 것을 완전히 이해합니다.

즉, yarn 가 내가하는 일을 알고 있다고 믿고 --no-save 플래그를 전달할 수 있기를 바랍니다. 문제가 발생하면 무엇이 잘못되었는지 정확히 알 수 있으며 책임을 져야합니다. :미소:

내 사용 사례?
나는 64 비트 윈 머신을 실행한다.
Prod 머신은 32 비트입니다.

패키지를 업데이트하지 않는 한 32 비트 만 지원하는 Node-sass 종속성.

dev 시스템을 지원하기 위해 package.json 또는 yarn.lock의 종속성을 변경하지 않습니다.
따라서 64 비트를 지원하기 위해 최신 node-sass를 로컬로 설치하고 싶지만 package.json 및 yarn.lock에는 영향을주지 않습니다.

VSCode에서 더 나은 자동 완성을 위해 package.json / yarn.lock 를 오염시키지 않고 비 TypeScript 프로젝트에 @types/* 패키지를 설치하고 싶습니다.

나는 실 작업 공간과 함께 lerna를 사용합니다.
@ types / [email protected] 업데이트로 인해 Antd의 유형 정의가 중단됩니다.
Antd는 주말에이 문제를 해결합니다.
하지만 지금은 현재 package.json에 영향을주지 않고 수동으로 @ types / [email protected] 의 고정 버전을 workspaceRoot에 설치하도록 원사를 강제해야합니다 (최신 버전을 자동으로 설치하기 때문에).

package.json에 저장하는 기본 동작을 유지하는 것은 옳지 만 실제로는 개발자가 package.json에 영향을주지 않고 모듈을 설치해야하는 경우가 있습니다. 특히 일부 패키지에 예기치 않은 주요 변경 사항이있는 경우.

암시 적으로 패키지를 업데이트하고 암시 적으로 package.json에 저장하면 충돌이 발생합니다.

여기 또 다른 사용 사례가 있습니다. 저는 React 라이브러리를 유지하고 있습니다. 새 버전을 게시하기 전에 여러 버전의 react 및 react-dom 에 대해 테스트를 실행하여 변경 사항이 역방향 및 정방향 ( @next ) 호환되는지 확인하려고합니다. 아래 설정을 사용하여이 작업을 수행했지만 이제 Yarn의 작업 영역을 사용하고 싶으므로 Yarn으로 마이그레이션해야합니다.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

이 스크립트로 package.json 를 변경할 수 없습니다. 그러면 게시 명령 ( pack publish )이 준비되지 않은 변경으로 인해 실패하게됩니다.

package.json 파일을 건드리지 않고 테스트 목적으로 CI 파이프 라인에 추가 패키지를 추가하고 싶습니다 (읽기 전용 파일 마운트 일 수 있음).
이들은 개발 구성 요소의 일부가 아닙니다.
개발 머신에서 개발 및 테스트하는 동안에는 설치되지 않아야하며 빌드 및 생산 중에 설치되지 않아야합니다. 테스트 중에는 CI 서버에서만 필요하고 허용됩니다.

이것은 npm을 사용하여 작동하지만 yarn은 npm에 대한 의존성을 제거 할 수 있어야합니다.
이것은 우리가 실만 사용하는 대신 npm 만 사용하도록 다시 가져올 수 있습니다.

또한 npm이 할 수있는 일을 할 수 없기 때문에 npm을 완전히 대체 할 수 있다는 약속을 깨뜨립니다.

또한이 기능은 일반적인 사용 사례가 아니라 엣지 사용 사례 여야하기 때문에 일부 플래그 뒤에이 기능을 절대적으로 숨 깁니다.

농담 해? 간단한 스위치를 추가하는 데 3 년이 걸리나요?

또 다른 사용 사례 : 사전 커밋 확인을 위해 npm 패키지 ( git-hoooks )를 사용합니다. 팀의 모든 사람이 노드를 설치하지 않았으므로 package.json에 포함하면 일부 사용자의 커밋이 중단됩니다. 그래서 git-hooks를 설치 / 제거하여 일시적으로 후크를 활성화 / 비활성화하는 npm 스크립트를 만들려고합니다. 겉보기에 간단하고 쉬운 작업이 실로 거의 불가능하다는 것을 알게되어 매우 실망했습니다.

yarn.lock이 더 이상 node_modules의 내용에 대한 진실의 원천이되지 않을 것이라는 점이 걱정된다면, 뭐가 그렇게 나쁠까요? 기존 함수가 추적되지 않은 종속성의 존재를 단순히 무시할 수 없었습니까? Yarn은 훌륭한 도구이며 메인테이너는 JS 커뮤니티에 훌륭한 서비스를 제공했지만이 결정을 재고해야합니다.

농담 해? 간단한 스위치를 추가하는 데 3 년이 걸리나요?

@spanasik 및 @Ryuurock : 무료로 제공되는 고품질 소프트웨어에 대해 논의 할 때 예의를

스위치는 구현하기가 너무 복잡하기 때문에 "3 년"이 걸리지 않았습니다. 이는 관리자가 이것이 사용자에게 순이익이 될 것이라고 확신하지 못하기 때문입니다. 이에 동의하지 않는 경우 기능에 대한 주장을하십시오.

@NickHeiner 여기에 10 개의 인수 화면이 있습니다. 그리고 좌절감을 유발하는 가장 중요한 것은 메인테이너가 확신하지 못하는 것이 아니라 그들이 그것을 무시하고 있다는 것입니다. 사람들이 "이에 동의하지 않고 기능에 대해 논쟁을 할 때"논쟁에 응답하지 마십시오. 그리고 사람들이 좌절하면 당연히 불쾌한 말을 남깁니다. 사용자에게 모든 것을 탓하지 마십시오.

나는 메인테이너가 여기서 논의하는 것이 더 나을 것이라는 데 동의합니다. 수년에 걸쳐 광범위한 사람들의 관심이 분명히 있습니다. 그래서 아마도 @spanasik 과 @Ryuurock 이 단지 "

그리고 사람들이 좌절하면 당연히 불쾌한 말을 남깁니다. 사용자에게 모든 것을 탓하지 마십시오.

동의하지 않습니다. 이 무례 함은 여전히 ​​유용한 진전이 아니며 성인들 사이에서 용인되는 행동도 아닙니다. 무례하다는 것은 관리자가 이것을 무시하는 것을 정당화하는 좋은 방법입니다 : "쓰레드는 단지 트롤입니다".

발전을위한 건설적인 방법 :

1. 다른 채널에서이 스레드에 대한 관리자의주의를 끌고 (아마도 무시했을 수도 있습니다) 동의하지 않더라도 적어도 여기서 주장을 인정하도록 요청하십시오.
2. 원사를 포크 / 교체하고 사람들이 더 행복한 방식으로 프로젝트를 관리합니다.

편리한 트릭은 yarn add --dev pkg && yarn remove pkg 입니다. 같은 일을합니다. 잠금 파일은 이전과 동일하게 유지되므로 그대로 유지됩니다.

테스트 됨-작동하지 않습니다.

내 사용 사례는 다음과 같습니다.
일부 패키지에는 'require'로로드되는 선택적 추가 기능이 있습니다. 이러한 추가 기능을 devDependencies 섹션에 추가하고 싶지 않기 때문에 'yarn add my-add-in'을 수행하고 package.json 파일에서 수동으로 제거합니다. 내 클라우드 CI 파이프 라인에서 'npm i'를 사용하여 추가합니다 (테스트 용). 내 로컬 파이프 라인에서 추가 잠금 파일을 생성하기 때문에 npm을 사용하고 싶지 않습니다. 이제 가장 좋은 방법은 npm을 사용한 다음 잠금 파일을 삭제하는 것입니다 (진실의 두 번째 버전을 제거하기 위해).

그래서 모든 것을 읽은 후 관리자에게 내 질문은 다음과 같습니다.

• 왜 그렇게 일관성이 없습니까?
• 모든 기능을 통해이 철학을 바로 구현하는 것은 어떨까요?
  
  
  
  • 즉, 우리 모두를 위해 일을 수행하는 방법을 결정하고 모든 기능에서 다른 모든 옵션을 제거하십시오. 코스를 유지하십시오! 항상 진실하라!
  
  

부인할 수없는 사실은 좋은 소프트웨어는 사용자가 자신의 상황에 가장 적합한 것을 선택할 수 있기 때문에 모든 좋은 소프트웨어에는 구성 설정이 있다는

간단하고 빠르기 때문에 실을 정말 좋아 합니다. 커뮤니티가 일을 작동시키기 위해 느리게 신뢰할 수있는 npm으로 되돌려 야하기 때문에 관리자가 확실히 풀어야 할 전투에 맞서 싸우는 것은 정말 불행한 일입니다.

온도를 조금 낮추자. 아무도 혐오감을 느낄 필요가 없습니다.
무료로 사용할 수있는 소프트웨어입니다.

On Wed, Jan 15, 2020 at 23:17 Hajime Yamasaki Vukelic <
[email protected]> 작성 :

실이 나를 특정 방식으로 일하게 만드는 것이 역겹다. 나는
스스로 결정하고, 내 도구가 어떻게
작동해야하고, 내 지능이 문제 중 가장 적다고 모욕해야합니다.
일을 완수 할 수 없다는 것이 가장 큰 것입니다.

완벽한 규칙을 믿고 절대로
그들을 깨는 것은 순진합니다. "모범 사례"와
"do-or-die". Oliver Wendell Holmes Sr.는 다음과 같이 말합니다.

젊은이는 규칙을 알고 있지만 노인은 예외를 알고 있습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFWSVREXG43ZLO17586 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

자신의 패키지 관리자를 만드십시오. 아무도 당신이 아무것도하도록 만들지 않습니다.

전혀 화를 내지 않고 논리의 오류를 지적하십시오.

실은 나를 특정한 방식으로 일하게합니다.

Yarn은 당신이 아무것도하도록 만드는 것이 아닙니다. 그들은 도구 (무료)를 만들었고 그것은 특정한 방식으로 작동합니다. 마음에 들지 않으면 다른 것을 사용하십시오.

@foxbunny 혐오감을 명확히 해주셔서 감사합니다. :)

이 경우에 합리적이고 혐오감을 느끼는 것이 합리적이라고 생각하더라도 무료로 사용할 수있는 도구를 만든 사람들에게 언어가 정중하게 이야기하는 방법이라고 생각하지 않습니다. 존중하면서 건설적인 피드백을 줄 수 있습니다.

@whitecolor 팀이 포인트를 얻었습니다. 그 옵션 --save는 어리 석습니다. Yarn은 node_modules, package.json 및 잠금 파일 간의 평형을 보장합니다. 더 안전합니다 .... npm --save는 위험합니다. 여러 번 나를 실망 시켰어

제발 그만해

아니면 모두가 더 낫다고 생각하고 진정되는 방식으로 작동하는 도구를 사용하는 것은 어떻습니까?

내 사용 사례는

앱의 하위 종속성을 업데이트하고 싶습니다.
이 종속성을 yarn link
그런 다음 앱에서 연결된 하나를 사용합니다.
라이브러리에 종속성을 추가합니다.
yarn install (wtf no.1) 이후 메인 앱에 lib 의존성이 추가되지 않습니다.
그런 다음 앱에 저장하지 않고 신속하게 추가하면 lib에 업데이트를 게시하기 전에 작동하는지 확인할 수 있습니다.
하지만-아니요.

감사

작성자가 무시한 커뮤니티를 보니 죄송합니다.

오픈 소스 자원 봉사자로서 일관된 철학이나
프로젝트는 진흙 덩어리로 분해됩니다. 이것은 때때로 말하는 것을 의미합니다.
사람들은“아니오”. 동의하지 않는 경우 나만의 패키지를 만들 수 있습니다.
마치 원사가 npm을 교체 한 것과 같습니다.

2020 년 3 월 3 일 화요일 03:53 Artur Kwiatkowski [email protected]
썼다 :

작성자가 무시한 커뮤니티를 보니 죄송합니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNENTG939XHJKTDN5W939XHJJKTDNM
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

저는 Lerna를 사용하고 있으며 프로젝트가 이미 이전 단계에서 빌드되고 아티팩트가 전달되었으므로 게시 단계를 위해 CI 단계 중 하나에 _only_ Lerna를 설치하고 싶습니다. 이것이 유효한 시나리오입니까?

^ 내 원래 의견-솔직히 왜 이것이 필요한지 모르겠고이 스레드가 그렇게 끔찍하게 날아갈 줄 몰랐습니다.하지만 몇 년 동안 이메일을 보는 것은 재미 있습니다.

나는 여기에있는 관리자들과 동의하는 경향이 있습니다.

1. 나는 내 주장에 확신이 없다. 나는 관리자가 어리석은 주장이라고 부르지 않고 예의 바르고 있다고 생각합니다.
2. 누군가가 PR을 제기한다고하더라도 기능의 지속적인 유지 관리가 유지 관리 담당자에게 더 큰 부담이되어 핵심 제품을 유지하는 데 방해가된다는 의미입니다.
3. 이러한 종류의 기능은 가정하지 못하는 초보자 및 / 또는 상대적으로 숙련되지 않은 원사 소비자에 의해 오용되어 포인트 2를 계속 유지합니다.

어쨌든이 기능의 필요성을 완화 할 수있는 더 좋고 구조적으로 더 건전한 방법이있을 것입니다.

이 기능을 구현하기 위해 yarn-add-no-save 를 만들었습니다. 프로젝트에 로컬 또는 전역으로 설치할 수 있습니다.

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

일단 설치되면 간단히 실행할 수 있습니다.

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

내 사용 사례는 peerDependencies 를 선언하는 모듈을 테스트하여 도구에 자동으로 설치하는 몇 가지 옵션이 있으므로 실행되는 모든 옵션을 확인하는 것입니다.

$yarn add-no-save --help

참고 : 패키지를 저장하지 않고 패키지를 설치하기 위해 패키지를 저장하는 것은 아이러니하고 기본적으로 목적에 맞지 않는다는 것을 알고 있습니다.하지만 이것이 제가 생각 해낼 수있는 최선의 방법이며 내 요구에 맞습니다.

이것은 특히 peerDeps 지원에 매우 유용합니다. 감사합니다.

이 기능에 대한 몇 가지 좋은 주장이 있습니다. 그것은 기본적으로하는 것과는 다릅니다. 사람들은 그것을 필요로하는 사람들 만이 그것을 사용할 것이라는 명확한 깃발 뒤에 그것을 요구하고 있습니다. 현재 다른 라이브러리와 마찬가지로 저장하고 싶지 않은 다른 라이브러리 버전을 사용하여 CI 중에 테스트를 수행해야합니다. 나는 여기서 이해하기 어려운 것이 무엇인지 이해할 수 없습니다.

yarn install xxx 다음 yarn remove xxx 합니다.

이 사용 사례가 논의 된 적이 있는지 확실하지 않습니다. 내 상황을 설명해 보겠습니다. 하나의 리포지토리에 서로 의존하는 패키지가 많이 있습니다. 그들은 모두 루트 서비스 하위 프로젝트에서 공통 패키지와 동일한 외부 종속성을 사용하며 각 로컬 패키지는 다음이 소비 할 순서대로 빌드되어야합니다. 나는 이것을 위해 원사 작업 공간을 사용하려고합니다. 시작하려면 루트 package.json에 정의 된 로컬 패키지가 없습니다. 모든 구성 요소를 빌드하는 한 전체주기 후에는 해당 로컬 종속성으로 완전히 업데이트 된 루트 package.json을 갖게됩니다. 이제이 업데이트 된 패키지가 CI에 빌드되면 추가 된 모든 로컬 패키지가 비 가용성으로 인해 실패합니다. CI에서 작동하려면 새로 추가 된 항목을 제거해야합니다.

yarn install xxx 다음 yarn remove xxx 합니다.

똑같다

다음은이를 수행 할 수있는 사용 사례입니다.

우리는 도구 내에서 "어플라이언스"를위한 모듈 식 에코 시스템이있는 도구를 구축하고 있으며, 계획은 해당 어플라이언스로 로컬 인스턴스를 설정하고 구성을 통해 동적으로 활성화하는 것입니다. 어플라이언스는 npm에 게시됩니다 (원하는 경우 프레임 워크 외부에서 호출 할 수 있음).

바닐라 프로젝트는 이러한 패키지에 의존 하지 않으므로 package.json 저장하는 것은 부적절합니다. 특정 인스턴스의 구성은 패키지 중 하나를 로컬에 설치해야 할 수 있습니다.

이 기능이없는 것은 우리 프로젝트에 제한적인 결정 인

여기서 "관리자"답글을 읽기 전에는 내가 가장 고집이 센 사람이라고 생각했습니다.

거의 4 년 ... 🤦

"고집"은 "디자인 비전이 있고 누구가 요구하는 모든 것을 구현하지 않는 것"과는 다릅니다.

"고집"은 "디자인 비전이 있고 누구가 요구하는 모든 것을 구현하지 않는 것"과는 다릅니다.

디자인 비전은 행복한 길을 설명하고 여기에서 요청한 탈출 해치로 더 넓은 커뮤니티에 유용성을 더합니다.

"자유 형식"설치 및 현상 유지의 증분 스냅 샷 ( node_modules )을 추적하는 잠금 파일에 섹션을 추가하여 안전하게 되돌릴 수있는 이유는 무엇입니까? 또는 node_modules와 별도의 폴더에 종속성을 넣고 node_modules를 사용하여 패키지에 링크가 노출되도록 유지하면 Yarn은 실제로 자체적으로 항목을 관리하고 보이지 않는 설치가 항목을 덮어 쓰거나 깨뜨릴 염려가 없습니다.

Git은 수십 년 전에이 문제를 해결했습니다. 따라 잡으세요! 뭔가 생각해 내세요! 그것이 바로 디자인입니다-한계를 극복하는 것 (또는 그것에 굴복하는 것보다).

여기 양쪽 끝의 터널 비전은 무지, 지나친 생각, 불필요한 양극화에서 비롯됩니다. 무술도, 철학도, 혁명도, 정치도 없습니다. 도구, 코드 묶음 및 수행해야 할 작업이 있습니다. 도구가 작업을 완료하는 데 도움이되지 않는 경우 해당 특정 시나리오를위한 도구가 아닙니다. 그리고 Yarn과 같이 대체에 범용으로 사용되는 도구의 경우 여기에서 무시되는 일반적인 시나리오가 너무 많아서 단순히 자체 무덤을 파는 것입니다.

나는 우리가 그냥 돌아 다닐 수있을 때 모두가 좁은 언덕을 서로 밀어 붙이는 것처럼 느껴진다.