Yarn Cache Clean: Yarn 캐시 삭제 방법 (v1, Berry)

간단한 답변: 사람들이 검색하는 yarn clear cache 및 yarn 캐시 지우기, 하지만 Yarn의 CLI 은(는) ~을(를) 사용합니다 yarn cache clean. 어떤 Yarn 버전을 사용하는지 확인하세요:

yarn --version

실행 yarn config get enableGlobalCache 유효한 설정을 확인하세요. Berry 플래그: yarn cache clean --all 활성 캐시 스코프와 활성화된 미러를 지웁니다. 하지만 머신에 있는 모든 글로벌 및 프로젝트 캐시를 항상 지우는 것은 아닙니다. yarn cache clean --mirror 별도의 미러가 존재할 때만 제거하며, 없으면 아무 동작도 하지 않을 수 있습니다. 경로 확인: Classic yarn cache dir 버전별 캐시 폴더를 출력하며, 전체 yarn cache clean 는 상위 캐시 루트를 삭제합니다. Berry yarn config get cacheFolder.

명령어를 실행했는데 yarn install에서, 방금 업데이트한 의존성이 여전히 구버전 빌드로 해석됩니다. 또는 로컬에서는 정상적으로 설치되는데, lockfile의 무해한 변경 후 CI에서 갑자기 실패하는 경우입니다. 캐시 동작은 Yarn Classic 과 Yarn Berry의 차이, 캐시 범위, 그리고 실제 문제가 lockfile인지 파이프라인 캐시 설계인지(단순 저장된 tarball이 아닌)에 따라 달라집니다. 더 넓은 CI 의존성 관리에 대해서는 Capacitor OTA 업데이트 CI/CD 통합.

목차

• 빌드가 실패했다면 Yarn Cache가 원인일 수 있습니다
• Yarn 캐시를 삭제해야 하는 시점과 이유
  • 캐시 문제를 의심해 볼 수 있는 증상들
  • Yarn clear cache를 쓰면 안 되는 경우
• Yarn Classic v1에서 Yarn 캐시 정리
  • 명령어가 실제로 삭제하는 것
  • 캐시 위치 확인 방법
• Yarn Berry v2+의 모던 캐시 관리
  • Berry가 캐시 모델을 바꿨다
  • Berry에서 꼭 알아야 할 명령어
• CI/CD 및 Docker를 위한 Yarn 캐시 베스트 프랙티스
  • 파이프라인에서 캐시를 비우는 게 대개 잘못된 선택인 이유
  • 더 나은 CI 및 Docker 접근 방식
• Yarn cache clean 문제 해결
  • 특정 대상만 clean해도 오래된 패키지가 남을 때
  • 캐시 문제처럼 보이는 권한 및 환경 문제
• Yarn 캐시 삭제 관련 자주 묻는 질문
  • yarn clear cache의 올바른 명령어는 무엇인가요?
  • Yarn Classic과 Yarn Berry에서 yarn cache clean을 실행하는 방법은?
  • Yarn 캐시를 지워도 안전한가요?
  • CI나 Docker에서 Yarn 캐시를 지우지 말아야 하는 경우는?
  • Yarn이 캐시를 어디에 저장하는지 확인하는 방법은?
  • yarn cache clean 후에도 오래된 패키지가 남아있는 이유는?

빌드가 실패했다면 Yarn Cache가 원인일 수 있습니다

익숙한 패턴은 다음과 같습니다. 패키지 버전을 올리고, 최신 변경사항을 가져온 뒤, install을 다시 실행합니다. 명령은 완료되지만 앱은 여전히 이전 의존성이 존재하는 것처럼 동작합니다. 누군가 캐시를 지우라고 제안하면, 그것이 진짜 해결책인지 아니면 단순한 미신인지 궁금해집니다.

진짜 해결책이 될 수도 있고, 시간 낭비가 될 수도 있습니다.

Cache problems usually show up in a few predictable ways. A local package won’t refresh. CI pulls something unexpected. A fresh branch behaves differently from the main branch even though the lockfile says everything should match. If you’re already chasing broader pipeline instability, it helps to pair cache debugging with a more systematic build review, like this guide on Capacitor CI/CD 파이프라인의 빌드 실패 해결.

실무 원칙: Yarn clear cache를 유지보수 의식이 아닌 진단 도구로 취급하세요.

복잡한 점은 Yarn이 시간이 지남에 따라 캐시 모델을 변경했다는 것입니다. 오래된 프로젝트에서는 캐시가 전역적으로 공유됩니다. 새로운 프로젝트에서는 명령 플래그에 따라 캐시 정리가 프로젝트 로컬, 전역, 또는 둘 다를 포함할 수 있습니다. 따라서 팀원이 "Yarn 캐시만 지우면 된다"고 할 때, 첫 번째 질문은 다음과 같아야 합니다: 어떤 Yarn인가요?

그래서 좋은 캐시 해결은 상황 파악에서 시작됩니다. 로컬 머신인지 CI 러너인지, Yarn v1인지 Berry인지, 공유 캐시인지 프로젝트 캐시인지. 이걸 알면 명령어가 막연한 시도가 아니라 정확해집니다.

Yarn 캐시를 삭제해야 하는 시점과 이유

특정 실패 상황을 염두에 둘 때 Yarn 캐시를 비우는 게 좋습니다. 오래된 패키지 아티팩트를 제거하거나, 다운로드가 깨진 상태에서 복구하거나, Yarn이 처음부터 다시 빌드하도록 저장된 패키지를 의도적으로 지워야 할 때 가장 유용합니다.

캐시 문제를 의심해 볼 수 있는 증상들

다음과 같은 경우 캐시 문제가 원인일 가능성이 높습니다:

• 의존성 업데이트가 안 될 때: 버전을 변경하거나 로컬 패키지를 다시 빌드했는데도, 설치할 때 여전히 이전 아티팩트를 가져오는 경우입니다.
• 설치가 상태에 의존하는 듯 실패할 때: 한 머신에서는 되는데 다른 머신에서는 안 되고, 같은 명령어를 다시 실행해도 계속 같은 나쁜 결과가 재현되는 경우입니다.
• 로컬 디스크 공간을 확보해야 할 때: 이는 수명이 짧은 CI 환경보다 개발자 로컬 환경에서 더 중요합니다.

다른 상황은 캐시 문제처럼 보일 뿐일 수 있습니다. lockfile이 예상치 못하게 바뀌었거나, 워크스페이스 설정이 일관되지 않거나, Docker 빌드에서 잘못된 레이어가 무효화되는 경우라면 캐시를 지워도 근본 원인은 해결되지 않습니다. 앱 빌드를 하는 팀은 네이티브 툴링, JavaScript 의존성, 플러그인 업데이트를 함께 다루다 보면 이런 상황을 자주 겪습니다. 이런 맥락에서, Capacitor 프로젝트의 의존성 관리 에 관한 이 실용적인 개요는 곁에 두고 볼 만합니다.

패키지 트러블슈팅이 아니라 전반적인 머신 정리가 목적이라면 시스템 레벨 가이드도 도움이 됩니다. Mac 개발자 중 Mac 사용자를 위한 앱 캐시 정리 를 하려는 분들은 패키지 매니저가 저장 공간의 일부에 불과하다는 걸 자주 알게 됩니다.

Yarn clear cache를 쓰면 안 되는 경우

모든 설치 문제에 Yarn clear cache를 먼저 쓰지 마세요.

패키지 상태가 오래되었거나 손상됐다는 증거가 있을 때 사용하세요. 문제가 다음과 같은 쪽일 가능성이 크다면 건너뛰세요:

환경이 잘못되어 설치가 잘못된 경우, 캐시를 지워도 다음 잘못된 설치만 더 느려집니다.

이 차이를 아는 것이 시간을 절약해 줍니다. 캐시를 마법 같은 리셋 버튼으로 여기는 것에서 많은 무의미한 디버깅이 발생합니다.

Yarn Classic v1의 Yarn cache clean

Yarn Classic은 많은 개발자가 여전히 모든 Yarn 버전이 그렇게 동작한다고 생각하는 방식대로 움직입니다. 이는 global cache를 사용자 디렉토리에 두고, yarn cache clean 해당 공유 캐시를 삭제합니다. Yarn Classic 자체 문서에서도 그렇게 설명하면서, 다음 yarn 또는 yarn install 실행 시 사용자 디렉토리 모델에 따라 캐시가 다시 채워진다고 언급합니다. 관련 내용은 Yarn Classic 캐시 CLI 문서에서 확인할 수 있습니다..

명령어가 실제로 삭제하는 것

Yarn v1의 기본 정리 명령어는 단순합니다:

yarn cache clean

이 명령어는 현재 프로젝트뿐 아니라 공유 캐시 전체를 지웁니다. 같은 머신에서 여러 저장소를 오가며 작업한다면 이 점이 중요합니다. 그중 어느 저장소든 다음 install 때 패키지를 다시 받아와야 할 수 있습니다.

이 공유 캐시 설계는 Yarn v1이 프로젝트 간에 헷갈리는 동작을 만드는 이유 중 하나입니다. global cache에 남은 오래된 아티팩트가 다른 저장소에 영향을 줄 만큼 오래 살아남을 수 있고, 특히 로컬 패키지 개발을 할 때 더 그렇습니다.

Yarn Classic의 일반적인 실행 순서는 다음과 같습니다:

1. 먼저 clean 명령을 실행하세요: yarn cache clean
2. 필요한 경우 로컬 설치 산출물을 삭제하세요: node_modules 상태가 여전히 일관되지 않게 보일 때 다음으로 시도해 볼 수 있는 방법입니다.
3. 처음부터 다시 설치하세요: 실행 yarn install 다시 실행하여 의존성 그래프가 예상대로 해결되는지 확인하세요.

캐시 위치 확인 방법

캐시 디렉토리를 직접 검사하거나 삭제하려면, Yarn Classic은 해당 경로를 제공합니다:

yarn cache dir

CLI 명령어로 문제가 해결되지 않거나, 공유 또는 컨테이너화 환경에서 캐시 디렉토리의 소유자 계정을 확인해야 할 때 유용합니다.

Yarn Classic 1.22에서 yarn cache dir 는 캐시 루트 아래 버전별 폴더를 가리킵니다(예: v6 기본 macOS ~/Library/Caches/Yarn 트리). 패키지 이름 없이 전체 yarn cache clean 를 실행하면 버전별 하위 디렉토리가 아닌 해당 상위 캐시 루트가 삭제됩니다. 만약 cache-folder Yarn 파일과 비-Yarn 파일이 함께 저장되는 경로라면, 전체 클린 시 비-Yarn 파일도 삭제될 수 있습니다. 전용 캐시 루트를 사용하고, 삭제 전 상위 디렉토리를 확인하세요. yarn cache dir 캐시를 지우기 전에.

구형 툴체인을 사용 중이고 로컬 설정을 예측 가능하게 유지하려는 경우, 이 가이드는 Capacitor CLI 단계별 설치 와 함께 의존성 초기화와 잘 어울립니다.

두 번째 무작정 실행하는 클린업 명령어보다 수동 캐시 점검이 더 유용한 경우가 많습니다.

v1 프로젝트의 경우 개념이 단순합니다. 공유 캐시 하나, 광범위한 클린업 명령어 하나, 그리고 다음 설치 시 삭제된 항목이 다시 채워집니다.

Yarn Berry v2+의 모던 캐시 관리

Yarn Berry는 상황이 바뀌었습니다. Yarn v1에 익숙하다면 가장 큰 변화는 캐시 클린업이 더 이상 '글로벌 스토어 지우고 다시 시도'가 아니라는 점입니다. Berry는 더 정밀한 제어를 지원하며, 대상이 명확할 때 유용합니다.

Berry가 캐시 모델을 바꿨다

모던 Yarn에서는 캐시 동작이 프로젝트와 훨씬 긴밀하게 연결됩니다. 이는 Berry의 프로젝트 레벨 제어, Plug’n’Play, 그리고 의존성이 단일 머신 전체 캐시 모델이 아닌 리포지토리와 함께 존재할 수 있는 워크플로우라는 더 넓은 접근 방식과 부합합니다.

그래서 오래된 조언이 오해를 불러일으킬 수 있습니다. Yarn v1을 배운 동료 개발자는 하나의 명령으로 전역 캐시를 모두 지울 수 있다고 기대할 수 있습니다. Berry에서는 다음 관점에서 생각해야 합니다: scope.

모바일과 웹 파이프라인에서 서로 다른 빌드 출력을 다루고 있다면, 같은 scope 개념은 패키지 관리 밖에서도 적용됩니다. 이 빌드 유형 비교 는 환경 가정이 디버깅으로 번지기 쉽다는 좋은提醒입니다.

명령어 세부 사항 전에 간단한 시각적 설명을 드립니다:

Berry에서 꼭 알아야 할 명령어

최신 Yarn 문서에서 yarn cache clean 에서 현재 Yarn cache clean 명령어 레퍼런스를 확인하세요. Scope는 유효한 enableGlobalCache 값에 따라 달라집니다 yarn config get enableGlobalCache:

• 사용하면 enableGlobalCache: true (Yarn 4+ 기본값), yarn cache clean Yarn이 직접 사용하는 전역 공유 캐시를 삭제합니다.
• 사용하면 enableGlobalCache: false (Yarn 2 및 3 기본값), yarn cache clean 활성 캐시 디렉터리를 삭제합니다(기본값 ./.yarn/cache, zero-install을 위해 커밋되는 경우가 많으며, 커스텀 cacheFolder 이 다른 위치를 가리키면 그것도 함께 삭제됩니다).
• yarn cache clean --all 활성 캐시 스코프와 활성화된 경우 별도의 미러를 삭제합니다. enableMirror: false을 사용하면 다른 프로젝트의 전역 캐시가 남을 수 있습니다. enableGlobalCache: true을 사용하면 이전 프로젝트 로컬 .yarn/cache 이 남을 수 있습니다.
• yarn cache clean --mirror 미러 캐시가 존재할 때만 해당 미러 캐시를 삭제합니다. Yarn이 이미 글로벌 캐시를 직접 사용하는 경우 --mirror 아무것도 삭제되지 않을 수 있습니다.

사용 --all 현재 설정에서 Berry가 제공하는 가장 광범위한 클리닝을 수행한 후, 다음으로 확인하세요 yarn config get cacheFolder 그리고 오래된 파일이 남아 있다면 해당 경로를 검사하세요. 사용 --mirror 프로젝트가 미러를 사용하는지 확인한 후에만 실행하세요.

결정 포인트: Berry에서는 잘못된 범위를 선택하는 것이 캐시 정리가 “아무것도 하지 않는” 것처럼 보이는 주요 원인 중 하나입니다.

이것이 실질적인 차이점입니다. Yarn Classic은 기본적으로 범위가 넓었지만, Berry는 설계상 명시적입니다.

CI/CD 및 Docker를 위한 Yarn 캐시 베스트 프랙티스

CI/CD에서 Yarn 캐시를 무조건 지우는 것은 대개 실수입니다. 상태를 제거해 안전해 보이지만, 파이프라인의 속도와 재현성에 필요한 핵심 상태를 함께 지우는 경우가 많습니다.

더 유용한 질문은 이것입니다: 정확히 무엇을 캐싱하고, 무엇을 복원하는가?

파이프라인에서 캐시를 비우는 게 대개 잘못된 선택인 이유

CircleCI 토론에서 실제 프로젝트에서 많은 팀이 겪는 실패 패턴이 포착되었습니다. 느린 설치는 캐시 정리로 해결되지 않았습니다. 병목은 오래된 패키지 아카이브가 아니라 fetch 및 link 동작, 캐시 디렉터리 불일치, 그리고 누락된 것이었기 때문입니다. node_modules 캐시된 세트의 경로가, 해당 CircleCI Yarn 캐싱 스레드.

이것이 중요한 이유는 CI 시스템이 근본 원인을 '설치가 느리다'나 '의존성 단계가 불안정하다'는 모호한 증상으로 가리는 경우가 많기 때문입니다. 개발자는 캐시를 지우고 다시 실행하지만, 의미 있는 개선 효과를 보지 못합니다.

흔한 pipeline 실수는 다음과 같습니다:

• 잘못된 디렉터리를 캐싱하는 경우: restore 단계는 완료되지만, Yarn이 복원된 위치를 사용하지 않습니다.
• 워크스페이스 경로 무시: 루트 의존성은 복원되지만 워크스페이스 설치 작업은 여전히 다시 링크해야 할 수 있습니다.
• Docker 레이어를 잘못된 순서로 빌드하는 경우: 소스 code 복사본이 의존성 레이어를 무효화하여 패키지 설치가 매번 다시 실행됩니다.

CI에서 잘못된 설정으로 인한 캐시 미스는 캐시 손상과 매우 유사해 보입니다.

자동화된 환경에서 모바일 앱을 빌드한다면, 여기서 릴리스 툴링이 등장합니다. 팀들은 종종 GitHub Actions나 CircleCI를 배포 및 업데이트 시스템과 결합합니다. 이러한 더 넓은 워크플로우에서 한 가지 옵션은 Capacitor 앱을 위한 Capgo의 CI/CD 설정, 그리고 Capgo 클라우드 빌드 소개 패키지 매니저 및 빌드 캐시 전략과 함께 원격 네이티브 빌드를 지원합니다.

더 나은 CI 및 Docker 접근 방식

캐시 무효화는 감정이 아니라 의도적으로 사용하세요.

CI에서 신뢰할 수 있는 패턴은 다음과 같습니다:

1. 의존성 상태 기반 캐싱: 캐시 키를 다음 항목에 연결하세요: yarn.lock 관련 Yarn 설정 파일.
2. 설치 전 복원: 복원된 경로가 해당 환경에서 Yarn이 사용할 경로와 일치하는지 확인하세요.
3. 일관되게 설치: immutable 설정에서는 lockfile 정확성을 강제하는 install 모드를 사용하세요.
4. 실제 변경 시 무효화: Yarn 버전 변경, lockfile 업데이트, cache-path 변경은 캐시를 다시 빌드할 좋은 이유입니다.

Docker에서도 원리는 비슷합니다:

• 의존성 매니페스트를 먼저 복사하세요: 가능하면 의존성 설치 레이어를 애플리케이션 소스와 분리하세요.
• 이미지 빌드에서 불필요한 정리는 피하세요: 동일한 빌드 내에서 캐시를 삭제하면 유용한 레이어 재사용이 사라지는 경우가 많습니다.
• 사용자 소유권을 명확히 하세요: root가 생성한 캐시 디렉토리는 나중에 non-root 런타임 사용자의 설치 실패를 유발할 수 있습니다.

간단한 결정 테이블이 도움이 됩니다:

Yarn clear cache는 CI에서 구식 캐시 내용이 실제 문제임을 확인한 경우에만 사용하세요. 대부분의 경우 더 나은 캐시 설계가 해결책입니다.

Yarn cache clean 문제 해결

가장 짜증나는 캐시 버그는 캐시 클리닝을 해도 사라지지 않는 것입니다. 대상 정리를 하고 재설치를 해도 Yarn은 여전히 오래된 패키지를 가져옵니다. 그 시점에는 레지스트리가 잘못되었거나 lockfile에 문제가 있다고 생각하기 쉽습니다.

Yarn의 문서화된 과거 이슈에서 그 원인을 알 수 있습니다. 개발자들은 yarn cache clean <package-name> 이 오래된 사본을 cache/.tmp에 남길 수 있다고 보고했으며, 이는 해당 임시 디렉터리가 삭제되거나 전체 클리닝이 실행될 때까지 설치가 항상 구버전을 사용하게 만들었습니다. 이는 의 오래된 캐시 아티팩트에 관한 Yarn 이슈에서 논의되었습니다 .tmp.

특정 대상만 clean해도 오래된 패키지가 남을 때

교훈은 단순합니다. 부분적인 클리닝만으로는 항상 충분하지 않습니다.

전반적인 손상이 아니라 버전이 낡은 것이 의심된다면, 다음 순서로 진행하세요:

• 가장 먼저 기본 확인부터 시작하세요: 디버깅 중인 패키지 버전과 소스가 예상과 맞는지 확인하세요.
• 패키지별 클린을 너무 믿지 마세요: 타깃 정리 작업은 임시 아티팩트를 남길 수 있습니다.
• 전체 캐시 삭제로 넘어가세요: Classic에서는 다음을 실행하세요 yarn cache clean 패키지 이름 없이 실행한 후 yarn install. Berry에서는 다음을 사용하세요 yarn cache clean --all 설정에서 허용하는 가장 넓은 범위로 실행하세요.
• 임시 캐시 경로를 직접 확인하세요: 이전 설정 방식에서는, cache/.tmp 빠진 퍼즐 조각일 수 있습니다.

패키지가 계속 예전 아티팩트를 가리킨다면, 타깃 정리가 실패한 뒤 가장 먼저 확인할 곳은 보통 임시 캐시 파일입니다.

캐시 문제처럼 보이는 권한 및 환경 문제

모든 “캐시 오류”가 캐시 콘텐츠 문제인 것은 아닙니다.

Docker, 다중 사용자 Linux 시스템, 또는 CI 러너에서는 Yarn을 실행하는 프로세스와 캐시 디렉토리의 소유자가 달라 권한 오류가 발생할 수 있습니다. 이 경우 소유권 문제가 해결되기 전까지는 캐시 클리어가 도움이 되지 않습니다. 실용적인 해결책은 Yarn을 올바른 사용자로 실행하거나, 재설치 전에 디렉토리 소유권을 복구하는 것입니다.

이런 문제는 환경마다 설치가 불규칙하게 실패하기 때문에 오래된 캐시 문제처럼 보이는 경우가 많습니다. 해결책은 운영 측면에 있고 패키지와는 무관합니다.

Yarn 캐시 삭제 관련 자주 묻는 질문

yarn clear cache의 올바른 명령어는 무엇인가요?

Yarn에는 yarn clear cache 서브커맨드가 없습니다. 문서에 나온 명령어는 yarn cache clean입니다. Yarn Classic v1에서는 사용자 디렉터리의 전역 캐시를 비웁니다. Yarn Berry v2 이상에서는 범위가 플래그와 실제 enableGlobalCache 과 yarn config get enableGlobalCache.

Yarn Classic과 Yarn Berry에서 yarn cache clean을 실행하는 방법은?

웹 Classic v1, 실행하세요 yarn cache clean, 그 다음 yarn install. 해당 경로를 확인하려면 yarn cache dir. Berry, 실행하세요 yarn config get enableGlobalCache (Yarn 4+는 기본적으로 true, Yarn 2와 3은 기본적으로 false). yarn cache clean 활성화된 캐시 범위를 지웁니다. 활성화된 범위와 활성화된 미러를 함께 지우려면 yarn cache clean --all 을(를) 사용하세요. 다른 전역 또는 프로젝트 캐시가 디스크에 남아 있을 수 있습니다. 별도의 미러가 존재할 때만 --mirror 을(를) 사용하세요.

Yarn 캐시를 지워도 안전한가요?

일반적인 개발에서는 네. 지우면 다운로드된 패키지 아카이브가 삭제되며 앱 소스는 유지됩니다. 다음 설치에 시간이 더 걸릴 수 있습니다. Classic에서는 yarn cache dir 이 버전별 캐시 폴더를 표시하지만, 전체 yarn cache clean 은(는) 상위 캐시 루트를 삭제합니다. 해당 상위 폴더를 확인하고 전용 cache-folder 커스터마이징했다면 Berry에서 실행하세요 yarn config get cacheFolder 전체 클린 전에. yarn cache clean 및 yarn cache clean --all 유효한 캐시 디렉터리 전체를 삭제합니다. enableGlobalCache: false을(를) 쓰면 보통 해당 경로는 ./.yarn/cache이지만, 커스텀 cacheFolder 은(는) 다음과 같은 상위 경로를 대상으로 할 수 있습니다 .yarn 에 있는 다른 프로젝트 파일까지 삭제할 수 있습니다. 별도 미러가 켜져 있으면 yarn cache clean --all 은(는) 아래의 캐시도 삭제합니다 globalFolder. 실행하세요. yarn config get globalFolder 첫 번째 제출이 승인되기 --all 해당 경로에 다른 파일이 있을 수 있습니다. 전체 클린은 일상 유지보수가 아닌 디버깅 단계로만 쓰세요.

CI나 Docker에서 Yarn 캐시를 지우지 말아야 하는 경우는?

설치가 느리지만 lockfile이 정확하다면 일상적인 캐시 지우기를 건너뛰세요. 먼저 캐시 키, 복원 경로, Docker 레이어 순서를 확인하세요. 캐시 지우기는 오래되었거나 손상된 패키지 아티팩트에 대한 증거가 있을 때만 수행하고, 기본 재시도 단계로 사용하지 마세요.

Yarn이 캐시를 어디에 저장하는지 확인하는 방법은?

웹 Classic v1, 실행하세요 yarn cache dir. On Berry, 실행하세요 yarn config get cacheFolder, yarn config get enableGlobalCache, 그리고 yarn config get globalFolder 미러 또는 yarn cache clean --all 사용 중일 때입니다. CI와 컨테이너에서 Yarn을 실행하는 사용자가 해당 디렉터리의 소유자임을 확인하세요.

yarn cache clean 후에도 오래된 패키지가 남아있는 이유는?

타겟 클린은 다음과 같은 임시 폴더에 파일을 남길 수 있습니다: cache/.tmp 구버전 Yarn에서. Classic에서는 다음을 실행하세요: yarn cache clean 패키지 이름 없이 실행한 후 yarn install. Berry에서는 다음을 사용하세요: yarn cache clean --all, 제거하고 node_modules 필요하면 재설치하고, 특정 패키지가 여전히 구버전으로 해석되면 임시 경로를 확인하세요.

팀에서 Capacitor 앱을 배포하고 의존성이나 빌드 문제 후 더 깔끔한 릴리스 파이프라인이 필요하다면, Capgo 스토어 리뷰를 기다리지 않고 JavaScript와 에셋 업데이트를 전달하면서 빌드 및 롤아웃 프로세스를 패키지 캐시 문제 해결과 분리할 수 있는 옵션 중 하나입니다.