<p>yarn은 아마도 파일 경로로 확인 된 패키지를 캐시해서는 안됩니다.</p>

이것도 저를 속였습니다. 모든 캐시를 지우지 않고이 문제를 해결할 수있는 방법이 있어야합니다.

이 경우에 실을 사용할 수있게 만드는 세 가지 방법이 있다고 생각합니다.

1. 모든 로컬 종속성을 무시 하라는 @donaldpipowitch 의 제안.
2. 파일이 캐시 될 때보 다 늦게 수정되는 경우 로컬 종속성을 다시 설치합니다. 이 메타 데이터를 유지해야합니다. 로컬 종속성의 경우 "Resolved"열에 다음과 같은 줄을 삽입 할 수 있습니다. file://<path>@<cache_timestamp>
3. yarn cache rm <package> 및 yarn cache add <package> 같은 명령을 사용하여 패키지 이름별로 패키지를 무시합니다. 모든 종속성.

구현할 두 번째 제안을보고 싶습니다. 세 번째 옵션은 다른 경우에도 유용 할 수 있습니다. 예를 들어 yarn cache add <package> 는 종속성을 다운로드하는 동안 문제가 발생할 수있는 경우 이미 캐시 된 종속성에 대한 캐시를 새로 고치는 데 사용할 수 있습니다.

@hantuzun 왜 로컬 종속성을 캐시합니까? 어쨌든 로컬이므로 캐시 여부에 관계없이 빠릅니다.

@ satya164 당신이 맞아요. 그러나 네트워크의 종속성이 의도적으로 수정되면 세 번째 접근 방식이 도움이 될 것입니다.

yarn cache ignore <package> 와 같은 것이 유용 할 것입니다. 하지만 서로 배타적 일 필요는 없다고 생각합니다. 패키지를 무시하는 것은 유용하지만 수동 작업이 필요합니다. 파일 종속성은 기본적으로 무시되는 경우 추가 노력없이 작동하도록 만들 수 있습니다.

누군가 나에게 내부 논리를 설명 할 수 있습니까?

내 이해 :
file: 가있는 종속성이 발생하면 file-resolver.js 시작됩니다. 종속성이 복사 되어야하며 해시 되지 않는다고 말합니다. 해시가 없다는 것은 이미 캐시되지 않아야 함을 의미하지 않습니까? 그러나 copy-fetcher.js 는 null 를 유지하는 대신 해시를 빈 문자열로 설정하는 것 같습니다 ...이 문제가 있습니까?

@bestander 또는 @kittens 아마도 당신은 이것을 조금 더 설명 할 수있을 것입니다 ...? PR을 만드는 데 약간의 도움을 받고 싶어요 ♥

Hash는 예를 들어 tarball-fetcher에 사용되는 md5 해시를 의미합니다.
이 해시는 향후 확인을 위해 yarn.lock 파일에 추가되며 압축이 풀린 폴더를 캐시에 저장할 때 폴더 이름에도 추가됩니다.
당신은 올바른 방향으로 파고 있습니다. 이것을 조사해 주셔서 감사합니다. PR은 대단히 환영합니다.
깨진 단위 테스트를 추가하는 PR로 시작할 수 있습니다.

깨진 단위 테스트를 추가하는 PR로 시작할 수 있습니다.

알겠습니다. 응답 해 주셔서 감사합니다. PR의 리뷰어로서 당신을 핑해야합니까, 아니면 다른 사람 (또는 아무도) 핑하지 않아야합니까 ...?

그래, 핑

@bestander 아마도이 문제는 아직 해결되지 않았

예, 다시 열어야합니다. 내 PR 제목에 "수정 # 2165"를 썼기 때문에 종료되었습니다. 처음에는 진행중인 PR이라고 생각했지만이 버그를 수정하려면 두 개의 PR이 필요합니다. 첫 번째 PR은 단위 ​​테스트를 추가했습니다 (실패 할 주장은 실제로 활성화되지 않으므로 CI가 폭발하지 않음). 두 번째는 실제로 그것을 고칠 것입니다.

죄송합니다. PR이 병합되면 github가 문제를 닫습니다.

그래서 분명히 이것은 여전히 ​​문제입니까? 솔직히 말해서 함께 개발하는 것은 상당히 성가신 일입니다. 그것은 모듈 식 개발 환경을 만들기 위해 file: 를 사용하고있는 직장에서 개인적인 수준에서 저에게 약간의 혼란을 야기하고 있습니다. 짜증나는 부분은 모든 로컬 패키지 내가 편집합니다 (사용한다는 점이다 file: 에서 경로 package.json ) 새로 고친 내용을 풀다운하기 위해,이 일이 필요합니다 :

내 eslint-config-base-eslint 패키지의 내용 편집

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

누구나 프로젝트에 기여할 수 있습니다.
이 케이스에 대해 깨진 통합 테스트를 제출하거나 수정을하거나 누군가가 수정 작업을하도록 설득하는 것은 무엇이든 될 수 있습니다.
이에 접근하는 가장 좋은 방법에 대해 이야기하고 싶다면 discord 채널에서 도움을 찾을 수 있습니다.

실제로 수정은 10-15 줄의 코드 여야한다고 생각합니다. 아마도 수정하는 데 많은 시간을 더 빨리 절약 할 수있을 것입니다.

참고 :이 문제는 느린 linking dependencies 단계와도 관련이있을 수 있습니다. 여기 내 의견을 참조하십시오 : https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

죄송합니다. 이 문제에 대해 또 다른 PR을 만들 시간을 찾을 수 없었습니다. (아직도 매우 바빴습니다.

@bestander 이것은 다중 모듈 프로젝트에서 작업하는 저에게 꽤 큰 차단기입니다. @donaldpipowitch 의 코드 링크와 주석을 올바르게 읽고 있다면 파일 해결 프로그램이 해결하려고 할 때마다 새 hash (null 대신)를 만들어 강제로 재설치하도록 할 수 있습니까? UUID 또는 현재 타임 스탬프를 말 하시겠습니까? 뭔가 빠진 것이 있으면 용서해주세요. 코드가 작동하는 방식에 익숙하지 않습니다.

타임 스탬프와 uuid가있는 새 캐시는 합리적인 해킹처럼 들립니다.
이상적으로는 캐시없이 직접 파일을 복사해야하지만
더 복잡한 변화.
PR 보내기

2017 년 3 월 7 일 화요일 03:38에 Matt Traynham [email protected] 은 다음과 같이 썼습니다.

@bestander https://github.com/bestander 이것은 꽤 큰 차단기입니다
나를 위해 다중 모듈 프로젝트에서 일하고 있습니다. @donaldpipowitch를 읽고 있다면
https://github.com/donaldpipowitch 의 코드 링크 및 댓글
올바르게, 파일 리졸버가 새 해시를 생성하도록 할 수 있습니까?
null) 해결하려고 할 때마다 강제로 다시 설치합니까? UUID 말하기
또는 현재 타임 스탬프? 빠진 게 있으면 용서 해줘 낯설어
코드가 작동하는 방식으로.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/yarnpkg/yarn/issues/2165#issuecomment-284612526 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
.

@bestander 귀하의 마지막 코멘트에 관하여 : 파일을 복사하는 대신 심볼릭 링크하는 것이 더 합리적이지 않습니까? 아니면 그렇게하지 않을 이유가 있습니까?

@danrot 창은 관리자가 심볼릭 링크를 요구하는 것 같습니다.
또한 노드 모듈을 찾기 위해 재귀를 엉망으로 만듭니다.

Symlink는 또한 .npmignore 등을 무시합니다. (현재 무시되는 것 같습니다. 문제가 될 수 있습니다 : https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

현재 전체 캐시를 지우는 것을 금지하는 해결 방법이 있습니까? 불행히도 yarn cache rm package 종류의 명령이없는 것 같습니다.

@ rhys-e이 작은 스크립트를 사용합니다.

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

누구는 것을 시도했다 yarn link 모든 로컬 종속성을 postinstall ? 적절한 해결책이 나올 때까지 적절한 해결책처럼 보입니다.

아이디어는 로컬 종속성에 대한 모든 변경 사항에 대해 패키지의 버전 번호를 업데이트 할 필요가 없다는 것입니다. 원사 링크는 그렇게하도록 강요 할 것입니다. (시도하지 않았다)

내 쪽에서 마지막으로 한 일은 로컬 종속성에 대해 소스 폴더와 node_modules 폴더에있는 내용을 비교하는 사전 설치 단계에서 스크립트를 호출하는 것입니다. 차이점이 발견되면 캐시 된 종속성을 제거하고 무결성 파일을 제거합니다 (강제 재설치를 위해). 따라서 변경 사항이 없으면 원사 설치가 매우 빠르며 (로컬 종속성이 많지 않음) 오래된 캐시 버전이 있으면 사용되지 않습니다.

@lucdew 링크는 기본적으로 내부에 심볼릭 링크를 생성하므로 최신 로컬 버전이 사용됩니다. 그러나 스크립트가 있으면 설치하기 전에 특정 deps의 캐시를 정리하는 것이 올바른 해결책이라고 생각합니다.

./node_modules/ 아래에 상위 프로젝트의 설치된 버전에서 업데이트되지 않는 로컬 패키지의 변경 사항을 해결하기 위해 다양한 조합을 테스트했습니다. ./node_modules/를 삭제할 필요없이 이렇게하면됩니다.먼저:

yarn cache clean; yarn upgrade file:../<package>

말할 필요도없이 로컬 패키지를 업데이트 / 업그레이드하기 위해 수동으로 전역 캐시 정리를 강제 할 필요는 없습니다.

@fungilation 해결 방법으로 npm을 사용하여 로컬 종속성을 설치하고 업데이트를 원할 때마다 전체 캐시를 잃지 않도록 할 수도 있습니다.

# 2860 및 후속 병합 커밋 https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24에 따라 이제 file: 프로토콜 종속성을 "새로 고침"할 수 있습니다.

yarn install --force

특정 패키지를 편집 하거나 업그레이드합니다 (이것도 잘 작동하는지 몰랐습니다). 종속성 버전이 변경되지 않은 경우 잠금 파일은 수정되지 않지만 최신 버전을 계속 복사합니다.

yarn upgrade [file protocol package name]

PR 변경은 캐시의 종속성을 무효화하고 로컬로 다시 설치합니다. yarn install 는 종속성 버전이 변경된 경우에도 작동하여 yarn.lock 파일이 무효화됩니다. 더 이상 캐시를 지우거나 로컬 설치에서 모듈을 삭제할 필요가 없습니다.

또한 link: 프로토콜을 사용하여 종속성을 연결하기위한 활성 RFC가 있음이 분명해졌습니다. https://github.com/yarnpkg/rfcs/pull/34에서 따를 수 있습니다

@mtraynham 풀 리퀘스트에 감사드립니다! 👌 이것은 굉장합니다. --force 이 필요한 이유는 무엇입니까? 나는 현재 그것을 찾지 않고 정확히 무엇을하는지조차 모릅니다. :) npm은 --force 플래그가 필요하지 않기 때문에 npm처럼 행동하는 것이 좋았을 것입니다.

같은 편집 외모 yarn upgrade [dependency] 아니라 작품. 지적하고 싶습니다. 이것이 항상 lockfile을 변경하는 것은 아니며 package.json 버전 변경 만 반영해야합니다. 업그레이드가 더 적절할 수 있으므로 원래 게시물을 업데이트했습니다.

짧은 버전은 Yarn이 잠금 파일이 변경되지 않은 경우 캐시 리졸버로 아무것도 수행하지 않으므로 잠금 파일 검사를 건너 뛰고 캐시에 새 버전이 있는지 물어봐야합니다. upgrade 또는 install --force 사용하여 수행 할 수 있습니다.

yarn install --force 문서 당

"이전에 설치된 패키지를 포함하여 모든 패키지를 다시 가져옵니다."

이것은 실제로 잠금 파일 무결성 검사를 건너 뛰는 것을 의미합니다. lockfile 무결성 검사는 일반적으로 package.json 파일을 변경하지 않고 정상적으로 복구하면 통과됩니다. 이를 건너 뛰면 캐시가 잠금 파일에 대해 누락 / 불일치 종속성을 확인하고 누락 된 경우 다운로드하고 새롭거나 누락 된 종속성을 로컬로 다시 복사하도록 요청합니다. 그런 다음 npm install / postInstall 스크립트를 실행합니다.

PR 변경은 이제 캐시에서 file: 종속성을 무효화하고 새 버전을 로컬로 복사합니다. 이전에는 file: 종속성을 무효화하지 않았습니다. 다른 프로토콜의 경우 package.json 파일을 변경하지 않은 경우 변경되지 않은 상태로 이동합니다 (캐시 및 로컬).

이것이 우리에게 무엇을 의미합니까? 하나의 file: 종속성과 함께 프로젝트 (Angular에서 Webpack까지 범위)에 대해 약 60 개의 종속성이 있습니다. 로컬 종속성 만 새로 고치고 싶은 두 번째 install --force 에서는 약 5 초가 걸립니다 ( yarn install ~ 1.5 초에서 증가). 나에게 이것은 매우 무시할 만하 며 실제로 전체 프로세스에서 작업 실이 얼마나 적은 작업을 수행하는지에 대해 매우 인상적입니다.

잠금 파일 검사를 건너 뛰고 특정 파일 종속성에 대해서만 캐시를 검사하는 또 다른 CLI 명령이있는 경우 더 빠를 수 있지만 아직 찾지 못했습니다.

말한 모든 것, 나는 이것을 반창고라고 부를 것입니다. 이것은 link: 와 같은 더 나은 솔루션으로 대체 될 수 있습니다. 나는 아무도 정말로 로컬 의존성을 캐시하는 데 관심이 없다고 생각합니다. 최소한 install --force 또는 upgrade 사용에 따른 추가 오버 헤드는 대부분 부주의하며 더 이상 yarn cache clean; mv node_modules /tmp/ .

좋은 대답입니다. 👏 적어 주셔서 감사합니다.

yarn이 로컬 심볼릭 링크 프로젝트 파일을 yarn 캐시의 파일로 덮어 쓰나요? (그게 일어나고있는 것처럼 보이기 때문에)

PR 변경은 이제 파일 : 캐시의 종속성을 무효화하고 새 버전을 로컬로 복사합니다.

내가 전화 할 때마다 그이 의미합니까 $ yarn 가지고 패키지 내부에 "foo": "file:../" 의 종속성과 같은 새 복사본 "file:../" 만들어집니다?

예를 들어 패키지이기도 한 여러 예제가있는 패키지가 있습니다.

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

그리고 지금은 foo 가 실 캐시에 10 번있는 것 같습니다. 또한 foo 의 모든 버전 변경에 대해 예제를 테스트합니다 (그리고 foo 뿐만 아니라 이러한 방식으로 구성된 여러 모듈이 있음). 그래서 현재 내 원사 캐시가 _really_ 빠르게 커지는 것처럼 보입니다.

이것이 올바른 행동입니까?

캐시에 오래된 버전을 사용하는 것보다 더 나은 대안이라고 생각합니다.
yarn 0.26을 사용하면 link: 를 사용하여 파일을 복사하는 대신 심볼릭 링크를 만들 수 있습니다.
또한 심볼릭 링크 생성을 자동화 할 작업 공간 ( https://github.com/yarnpkg/yarn/issues/3294) 을 작업하고

예, 작업 속도를 기대합니다 👍

link: 은 아직 npm에서 작동하지 않습니까? (https://github.com/npm/npm/pull/15900이 아직 열려 있기 때문입니다.)

npm 5 patchnote 에서 파일은 이제 file: 구문으로 자동으로 심볼릭 링크됩니다.

npm install ./packages/subdir은 이제 일반 설치 대신 심볼릭 링크를 생성합니다. file : //path/to/tarball.tgz 는 변경되지 않으며 디렉토리 만 심볼릭 링크됩니다. (# 15900)

네, npm에는 link 가 없습니다.

npm install ./packages/subdir은 이제 일반 설치 대신 심볼릭 링크를 생성합니다.

유감입니다. 모든 것을 복사 ( node_modules )하고 .npmignore 또는 files 필드를 존중하지 않기 때문에 파일 deps가 동일하게 작동하지 않았습니다. 이제 심볼릭 링크가 더 나빠졌습니다.

나는 file : and link : 더 개선 될 수 있다고 생각한다. 그들 자신의 장단점을 가진 다른 전략이 있고 Yarn은 사람들이 하나를 선택할 수 있도록해야한다.
예를 들어 knit RFC는 https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md 전략 중 하나로 구현 될 수 있습니다.

안녕하세요.

캐시에 오래된 버전을 사용하는 것보다 더 나은 대안이라고 생각합니다.

또는 디스크 공간이 부족하고 Yarn 캐시가 완전히 쓸모없는 수백만 개의 파일에 대해 수십 기가 바이트를 사용하고 있음을 발견 할 때까지 믿을 수
IMO는 일시적으로 개발 시스템을 망가 뜨린 경우에만 알 수 있기 때문에 이전보다 더 심각하게 모든 것을 망가 뜨리는 IMO입니다.

안녕하세요, 문제에 대한 업데이트가 있습니까? 특히 동일한 연결된 다중 종속성에 의존하는 여러 제품을 한 번에 작업 할 때 특히 큰 문제입니다. 개발 하루에 기가 바이트의 캐시 등. 적어도 선택 사항으로 만들고 그러한 패키지에 대한 캐싱을 비활성화 할 수 있습니까?

@nikdojo 종속성에 대해 file: 대신 원사 link: 프로토콜을 사용하고 심볼릭 링크를 사용합니다. 0.26 에서

또는 프로젝트 간 종속성이 많은 경우 작업 공간 사용을 시작하십시오.

힌트를 위해 @mtraynham Thx, 공식 문서에서 link: 프로토콜 정보를 찾으려고했지만 거기에없는 것 같습니다. 지금 작업 공간을 실험하고 있습니다.

@bestander btw 아시다시피 react-native는 심볼릭 링크를 지원하지 않으므로 rn libs로 작업하면 여전히 큰 문제입니다.

이것은 결코 해결되지 않았습니까? 로컬 패키지를 연결하려면 linklocal (NPM 패키지)을 사용해야합니다 (캐싱 대신 Windows에서 접합 또는 심볼릭 링크를 사용하여 로컬 파일 시스템에서 패키지를 사용할 때 yarn이 작동하는 표준 방식이어야 함). 새로운 yarn install 는 캐시에있는 오래된 항목으로 모든 것을 덮어 쓰고 다시 연결을 시작해야합니다.

우리는 건축 우주 비행사가 덜하고 단순히 로컬 패키지를 캐시하지 않을 수 있습니까? 이 문제는 이제 1.5 년이되었으며 another-local-package 에서 무언가를 변경할 때마다 yarn add ../<another-local-package> 실행하는 데 지쳤습니다.

안녕하세요 @fungilation
다른 관련 문제를 열었습니다 : # 6037

작동하지 않는다
App.js 파일에 넣었습니다.
console.log ( 'here we are'), 출력되지 않았습니다.
그런 다음 모든 파일을 제거해도 여전히 캐시에서 출력이 생성됩니다.
이것을 피하는 방법?

Yarn은이 문제에 대해 정말 실패했습니다. 이것을 제외하고는 다른 모든 것에 훌륭했습니다.

테스트 목적으로 새 버전의 로컬 패키지를 설치하려고했는데 내가 무엇을하든 계속 이전 패키지로 끝납니다.

난 노력 했어:

1. 원사 캐시 청소 ( yarn cache clean package-name )
2. yarn add 'ing with --force
3. 다시 node_modules/package-name 및 yarn add 제거
4. 로컬 패키지의 버전 번호 및 파일 이름 업데이트 ( yarn 은 최신 버전을 설치한다고보고하더라도
5. 위의 모든 조합

이건 말도 안 돼요. 저는 하루 중 거의 4 시간을 이것에 보냈습니다.

로컬 패키지를 개발하고 재설치 할 수있는 능력이 필요합니다 . .bin 폴더에 파일을 설치하기 위해 yarn에 의존하고 있으므로 yarn link 는 문제가되지 않습니다.

@ Yarn 개발자 : 로컬 패키지를 설치하고 해당 로컬 패키지를 변경 한 다음 다시 설치하여 변경 사항을 반영 할 수 있습니까?

@gregjacobs 저는 yarn install --force 성공했습니다

@jonathantorley 방금 --force 다시 시도했지만 원사 1.12.3에서는 여전히 작동하지 않습니다.

이 문제에 직면 한 다른 사람들을 위해 : 실제로 이것을 작동시키는 데 사용한 한 가지 해결 방법은 종속 패키지의 버전 번호를 높이는 것입니다. 약간 성가 시며 스크립트를 작성할 수없는 경우 변경 될 때마다 수행해야합니다.

yarn 은 (는) 로컬 패키지를 설치할 때이 해결 방법을 요구하지 않아야합니다.

preinstall 스크립트에 yarn upgrade MY_PACKAGE_NAME 했는데 최신 NPM 버전으로 잘 업그레이드됩니다. (그래도 NPM 버전을 수동으로 올려야합니다).

이제 yarn add file:PATH 은 (는) 이제 원사 1.13.0에서 항상 새 콘텐츠를 업그레이드하는 것 같습니다.
yarn install 아직 없습니다.

@leavesster 여전히 나를 위해하지 않습니다.

업데이트하려면 tgz의 이름을 바꿔야합니다.

link 명령을 사용해보십시오 : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH 에서 새 콘텐츠를 업그레이드하지 않았습니다. 또한 package.json 및 .npmignore의 파일은 존중되지 않습니다.

패키지 버전을 변경하면 작동합니다.

yarn add file:PATH 에서 package.json 및 .npmignore의 파일을 존중하도록하려면 로컬 패키지 종속성에서 yarn pack 를 실행 한 다음 설치하려는 위치에서 yarn add file:path-to-local-pacckage.tgz 실행해야합니다.

link 명령을 사용해보십시오 : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link 은 (는) 동일한 문제를 해결하기위한 것이 아닙니다. 누군가 package.json 및 .npmignore의 파일과 관련하여 게시 된 것처럼 npm 패키지를 원하는 경우 좋지 않습니다.

@leavesster 여전히 나를 위해하지 않습니다.

업데이트하려면 tgz의 이름을 바꿔야합니다.

내 패키지에 yarn add file: PACKAGE_PAH 를 사용하여 현재 프로젝트에 추가하는 tgz 가 없습니다. 내 패키지에 js 코드가 있습니다. 어쩌면 tgz가 여전히 틀렸을까요?

나를 위해 일하지도

@bestander 이 문제가 종결 된 이유는 무엇입니까? Yarn은 여전히 ​​로컬 파일과 tgz 패키지를 캐싱합니다. 예를 들어, 한 패키지에 특정 버전의 deps가 있고 다른 패키지에 첫 번째 패키지와 동일한 devDeps가 있지만 다른 버전이있는 경우, 그리고 한 패키지를 다른 패키지에 연결하면 프로젝트가 손상된 경우와 같이 일부 경우 작업 공간은 솔루션이 아닙니다. .

@gregjacobs와 같은 문제가 있습니다. yarn cache clean package 도움이되지 않았습니다. 하지만 yarn add path/to/package.tgz 를 설치 한 다음 아카이브를 다른 것으로 바꾸면 새 버전을 설치하면 yarn add path/to/../to/package.tgz 와 같은 경로

yarn cache list --pattern package 조차도 비어있는 해상도 경로로 캐시 된 패키지를 저장하는 다른 위치를 이해할 수 없습니다.

문제가 여기 어딘가에 있다고 생각합니다 https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

무슨 일이야:

• URL path/to/package.tgz 에서 해시를 생성합니다 (이것이 path/to/package.tgz 및 path/to/../to/package.tgz 결과가 다른 해시로 변환되는 이유입니다).
• 이 해시로 패키지에 대한 임시 디렉토리를 만듭니다 (예 /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 ).
• 첫 실행 isValidModuleDest 반환 false
• 이 디렉토리에서 추출 된 Tarball 패키지
• 프로젝트에 설치된 해당 디렉토리의 파일
• 개발 프로젝트 소스를 수정하고 이전 패키지와 동일한 이름 및 위치로 새 패키지 tarball을 빌드 / 패킹합니다.
• 그리고 새로운 tarball을 설치하려고하는데 생성 된 해시가 이전과 같고 첫 실행 후 임시 디렉토리가 지워지지 않았습니다.
• 따라서 이번에는 isValidModuleDest return true
• 그리고 원 사는 이전 버전의 패키지를 설치합니다.
• yarn cache clean package 를 실행하지만 임시 디렉토리는 그대로 유지됩니다.

@bestander 여기서 임시 디렉토리를 제거 할 수 있습니까? https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

같은 문제에 직면하여 임시 폴더 아래의 캐시는 단 하루 동안 로컬 pacakge에서 작업 한 후 10GB가 걸립니다!

이 문제를 다시 열 수 있습니까? 우리는 같은 문제에 직면 해 있습니다. 파일을 통해 다른 패키지를 참조하는 두 프로젝트 :. CI / CD 서버에서 일부 빌드 후 캐시 폴더가 많은 공간을 차지하기 시작합니다.

링크 프로토콜이 이에 대한 최선의 수정이라고 생각합니다. file : //은 여전히 ​​수동으로 캐시를 정리하고 강제 설치가 필요하기 때문에 작동하지 않습니다.

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

종속성을 다음과 같이 만드십시오.

"<package>": "link:./libs/<package>"

@alxtz 링크 프로토콜이 tgz의 패키지와 함께 작동합니까?

링크 프로토콜이 이에 대한 최선의 수정이라고 생각합니다. file : //은 여전히 ​​수동으로 캐시를 정리하고 강제 설치가 필요하기 때문에 작동하지 않습니다.

# 2165 (코멘트)

종속성을 다음과 같이 만드십시오.

"<package>": "link:./libs/<package>"

감사합니다. 이것은 node_modules 에서 file:.. 참조를 심볼릭 링크하는 NPM의 동작을 복제합니다. 문서화되지 않은 것 같습니다. 적어도 여기에서 찾을 수있는 곳은 없습니다 : https://yarnpkg.com/lang/en/docs/package-json/

안타깝게도 link 는 모든 경우에 사용할 수 없습니다.

예를 들어, SDK 패키지에서 공유 / 피어 종속성이 필요합니다. 변경하면 로컬 개발 작업을 위해 링크됩니다.
link 하면 yarn은 종속성이 공유 / 피어 종속성임을 인식하지 못하며 잘못된 심볼릭 링크가있는 로컬 패키지를 사용합니다.

내가 사용하고 yarn pack 함께 yarn add file:<path_to_packed_tgz> 이 문제를 해결하기 위해.
@wKich 환상적인 발견에 따라 동일한 해시를 생성하지 않도록 패키지를 포장하고 내 저장소에 붙여 넣을 때마다 패키지 이름을 계속 바꿀 수는 있지만 성가신 일입니다.

저장소를 분기하고 if 문에 추가 절을 추가하여 yarn이 yarn add file:<path> 사용하여 지정된 경우 캐시에서 로컬 .tgz 패키지를로드하지 못하도록합니다.

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

사람들이 원하면 PR을 할 수 있지만, 전에는 해본 적이없고 꽤 엉뚱한 수정입니다.
이 접근 방식이 원사의 캐시에 로컬 패키지를 계속 추가할지 여부를 누군가 확인할 수 있습니까?

지금은 @ojboj , yalc 이 (가) 제대로 수정 될 때까지 도움이 될 수 있습니다. 게시하기 전에 로컬에서 패키지를 테스트하는 것이 정말 잘 작동했습니다.

@souporserious 그것이 내가 필요로 / 원했던 것입니다. 정말 감사합니다!

미쳤어 이것은 수년이 지난 후에도 여전히 문제입니다.

[email protected]에 고정되어

@wKich 그렇게 믿습니다! 개인적으로 테스트하지는 않았지만 새로운 포털 프로토콜을 통해 로컬 개발을 해결하는 것 같습니다.

여전히 link: 프로토콜을 사용하여 "unpack in same destination"오류가 발생하고 캐시 디렉토리를 참조하고 있으므로 yarn이 여전히 link: 종속성을 캐싱하는 것 같습니다. 아래 오류에서 front-end 및 renderer 를 사용하는 각 앱의 .deps/ 폴더에 복사 된 동일한 로컬 패키지의 복사본 2 개를 참조하고 있습니다. (관련없는 이유로 원본에 연결할 수 없음)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.