원사 블로그 기반 :

yarn.lock이 포함된 패키지를 게시하면 해당 라이브러리의 사용자는 영향을 받지 않습니다. 애플리케이션이나 라이브러리에 종속성을 설치할 때 자신의 yarn.lock 파일만 존중됩니다. 종속성 내의 잠금 파일은 무시됩니다.

개별 패키지를 게시할 때 yarn.lock을 묶을 필요는 없는 것 같습니다... 전체 리포지토리에 대한 개발 아티팩트에 더 가깝기 때문에 각 패키지에 넣을 필요가 없습니다.

@connectdotz 라이브러리 또는 게시된 패키지에는 필요하지 않을 수 있지만 도커 컨테이너를 빌드하려면 확실히 있어야 할 어딘가에 배포하고 싶을 것입니다.

물론 ...하지만 개발 도커 컨테이너에는 전체 저장소가 있으므로 어쨌든 yarn.lock이 있습니까? 도커 컨테이너를 사용하여 다른 OS 또는 플랫폼에 대한 모노리포지토리 프로젝트를 테스트하는 것을 볼 수 있습니다. 이 경우 전체 리포지토리와 해당 yarn.lock을 배포하기만 하면 됩니다. 개발 주기 동안 monorepo 프로젝트의 개별 패키지를 도커 컨테이너에 배포해야 하는 사용 사례의 예를 들어 주시겠습니까?

따라서 우리는 전체 monorepo를 결과 도커 컨테이너에 패키징하고 싶지 않습니다. 우리는 프로덕션에서 docker를 사용하고 있으며 해당 이미지는 가능한 한 가벼워야 합니다. 모노 리포지토리는 상당히 크며 라이브러리 패키지를 사용하여 코드를 공유하는 여러 마이크로서비스를 포함합니다(일부 라이브러리는 일부 마이크로서비스와 관련되지만 전부는 아님). 따라서 마이크로 서비스를 패키징할 때 이미지에 해당 마이크로 서비스의 파일과 적절한 종속성으로 다른 모든 종속성이 포함되기를 원합니다. 프라이빗 레지스트리에서 다운로드하고 도커 이미지의 아치를 위해 빌드했습니다.

따라서 여기에서 주요 고려 사항은 도커 이미지를 가능한 한 가볍게 유지하는 것이며 전체 monorepo를 패키징하는 것은 우리의 요구에 맞지 않는다고 생각합니다. 또한 마이크로 서비스의 이미지 내에서 "yarn"을 실행할 때 거기에 심볼릭 링크를 원하지 않고 일반적인 종속성을 갖습니다.

여기에서 솔루션은 작업 공간마다 yarn.lock 파일을 생성할 필요가 없으며, 주어진 작업 공간을 패키징하는 과정, 주문형 작업 공간에 대한 yarn.lock 파일을 생성하는 등의 과정에 도움이 되는 yarn 명령일 수도 있습니다. ..

사용 사례를 명확히 하는 데 도움이 되었기를 바랍니다. 🍻

@netanelgilad 자세한 내용에 감사드립니다. 사용 사례가 프로덕션 또는 개발을 위해 도커 컨테이너에 개별 패키지를 게시 하는 것에 관한 것임을 명확히 하는 데 도움이 됩니다. 통합을 시작할 수 있도록 #4521의 토론에 참여하십시오.

개별 잠금 파일의 사용을 볼 수 있지만 필요하지 않습니다. 개별 파일을 가리키는 -f 플래그를 사용하여 repo의 루트에서 docker를 실행하면 전체 repo를 컨텍스트로 가지며 루트에서 package.json 및 yarn.lock을 복사할 수 있습니다.

이미지에 빌드할 패키지에 대해서만 package.json이 필요하며, yarn.lock에 훨씬 더 많은 것이 포함되어 있어도 yarn은 복사한 package.json 파일에 대한 패키지만 설치합니다.

편집 : 그 말과 함께. 빌드에 포함되어 있지 않더라도 도커 캐시가 모든 패키지의 패키지 변경에 사용되지 않도록 합니다.

4206은 관련/중복이며 여기에 설명된 사용 사례는 정확히 우리가 직면한 문제입니다.

10개의 다른 패키지가 있다고 가정해 보겠습니다. 우리는 사람들이 원할 경우 독립적으로 작업할 수 있도록 그들 모두가 자신의 저장소에 살기를 원하지만 필요한 경우 함께 연결할 수 있기를 원합니다. 이를 위해 각 패키지에 대한 하위 모듈이 있는 메가 리포지토리와 이러한 각 하위 모듈을 작업 공간으로 참조하는 package.json이 있습니다.

작업 공간과 비슷한 문제가 있습니다. 내 프로젝트는 많은 로컬 패키지에 따라 달라지는 web-app 입니다.

web-app/
|--node_modules/
|--packages/
|  |--controls/
|  |  |--src/
|  |  |--package.json
|  |--utils/
|     |--src/
|     |--package.json
|--src/
|--package.json
|--yarn.lock

작업 공간 패키지 controls 및 utils 은 게시되지 않으며 경로에서 사용됩니다. 문제는 controls 패키지( yarn pack )를 릴리스해야 하고 자체적으로 빌드/테스트하고 싶지 않다는 것입니다. 즉, yarn install 안에 web-app/packages/constols/ yarn install 하고 싶습니다. 작업 공간에서는 최상위 web-app/yarn.lock 파일을 최상위 web-app/node-modules/ 와 함께 사용합니다. 따라서 web-app/packages/controls/package.json 지정된 하위 집합 대신 모든 패키지를 설치합니다. 그러나 내 패키지에 자체 package.json 필요한 모든 종속성이 있고 다른 작업 공간에서 누락된 deps를 채우는 행운으로 작동하지 않는지 확인해야 합니다.

2가지 가능한 솔루션이 있습니다.

1. 루트가 아닌 경우 루트의 yarn.lock 를 사용하되 로컬 package.json 지정된 패키지만 설치합니다.
2. 최상위 구성을 검색하지 말고 .yarnrc/.npmrc .

이것도 고군분투. API와 함께 Angular CLI 프로젝트가 있으므로 동일한 저장소에 있고 프론트엔드를 Heroku로 푸시하려고 합니다.

Heroku에게 먼저 프론트엔드 저장소로 이동하도록 지시하는 빌드팩을 사용하고 있습니다. https://github.com/lstoll/heroku-buildpack-monorepo

문제는 nohoist 패키지 안에 yarn.lock 가 없으므로 Heroku는 npm으로 설치하고 잠긴 패키지가 아닌 모든 새 패키지로 끝납니다.

개별 패키지와 함께 전역 yarn.lock 파일을 사용할 수 있습니다. 최근에 다음과 같이 Dockerfile에 접근했습니다.

WORKDIR /app
ENV NODE_ENV=production

ADD yarn.lock /app/
ADD package.json /app/

# Only copy the packages that I need
ADD packages/my-first-package /app/packages/my-first-package
ADD packages/my-second-package /app/packages/my-second-package

RUN cd /app && yarn install --frozen-lockfile

이것은 다른 사람이 아닌 내가 복사한 두 패키지에서 실제로 사용 중인 종속성만 설치합니다.

먼저 한 패키지에서 릴리스 아티팩트를 만든 다음 해당 종속성을 설치하지 않으려는 빌드 프로세스가 있습니다. 이것은 Docker의 다단계 빌드로 상당히 쉽습니다.

1. 도커에 yarn.lock, package.json, UI 패키지만 추가
2. yarn install --frozen-lockfile
3. 빌드 프로세스를 실행
4. 새 단계를 시작하고 yarn.lock, package.json 및 필요한 런타임 패키지/작업 공간 폴더를 추가합니다.
5. 빌드된 아티팩트에 대해 COPY --from=<stage>
6. yarn install --frozen-lockfile 실행하고 RUN 명령을 노출합니다.

그리고 Yarn.lock 파일에 지정되고 프로덕션에 필요한 종속성만 포함하는 작은 컨테이너로 끝납니다.

@johannes-scharlach
나는 당신이 설명하는 것과 거의 동일한 방법을 사용하게 되었습니다. 다단계 빌드는 좋은 팁입니다 :).

@connectdotz 내 생각에 이 문제는 종료될 수 있으며 문제 #4521에 대해 계속 작업할 수 있습니다. 기본 yarn.lock 파일이 패키지의 하위 집합과 함께 작동할 수 있기 때문에 작업 공간당 yarn.lock이 필요하지 않은 것처럼 보입니다(비록 이것이 더 나은 개발 워크플로가 될 수 있다고 생각하지만 😉 ). 그러나 #4521의 문제는 여전히 중요합니다. 우리가 여기에서 얻은 솔루션에서 비록 yarn이 상호 의존성과 주어진 작업 공간을 "공급업체"로 알고 있어야 하지만 Dockerfile의 모든 종속성 작업 공간을 언급해야 하기 때문입니다.

저는 지난 며칠 동안 모노레포를 첫 번째 Lerna로 변환한 다음 Yarn 작업 공간으로 변환하는 데 시간을 보냈습니다. Yarn은 일반적으로 더 안정적으로 작동했으며 특히 최근 yarn workspaces run <script> 및 wsrun 과 같은 다른 멋진 기능이 도입되면서 우리가 필요로 하는 것과 매우 가깝습니다.

그러나 단일 yarn.lock 는 골칫거리입니다.

• 기존 잠금 파일을 단일 잠금 파일로 올바르게 마이그레이션하는 방법을 잘 모르겠습니다( https://github.com/yarnpkg/yarn/issues/6563 참조). 거기에는 수만 줄이 있고 작업 공간으로 기존 패키지를 추가하면 많은 미묘한 버전 문제가 발생합니다.
• 특정 패키지에만 종속성 설치("de-hoisting" / "vendoring") Docker화된 빌드는 잘 지원되지 않습니다. 위(https://github.com/yarnpkg/yarn/issues/5428#issuecomment-403722271) 또는 https: //github.com/yarnpkg/yarn/issues/4521.

Yarn 작업 공간이 특정 기능이 없는 패키지 선언인

• 작업 공간에서 일부 스크립트를 실행하려면 yarn workspaces run <script> 합니다.
• 단일 잠금 파일과 호이스팅을 원하면(두 개는 반드시 함께 묶여 있습니까?), 이것은 루트 package.json .
  json "workspaces": { "packages": ["packages/*"], "hoistDependencies": true }
• 현재 잠금 파일을 호이스트 구조로 마이그레이션하려면 yarn workspaces hoist-dependencies 합니다.

등은 예시일 뿐이며 실제로 일부 기능은 옵트인 대신 옵트아웃일 수 있지만(예: 사람들은 지금까지 단일 yarn.lock 및 호이스팅을 기대합니다) 일반적인 아이디어는 작업 공간이 repo 전체 작업을 위한 가벼운 기반이 됩니다.

어떻게 생각하나요?

이 기능 요청이 해결하고 있는 문제는 #4521에서와 동일하다고 생각합니다. @johannes-scharlach가 설명하는 것을 본질적으로 수행하는 명령은 작업 공간당 잠금 파일보다 확실히 더 실현 가능합니다.

또한 현재 중첩된 작업 공간에 대한 RFC가 열려 있습니다. 이 기능은 다른 문제를 해결하고 있다고 생각하지만 이 기능 요청과 비슷합니다.

Yarn 작업 공간이 특정 기능이 없는 패키지 선언인 작은 코어에 대해 어떻게 생각하십니까?

작업 공간은 크게 바뀌지 않을 것이며 현재 인터페이스에 만족한다고 생각합니다.

작업 공간에서 일부 스크립트를 실행하려면 yarn workspaces run <script>

그것은 이미 가능합니다(v1.10, #6244).

현재 잠금 파일을 호이스트 구조로 마이그레이션하려면 yarn workspaces hoist-dependencies 합니다.

작업 공간 인터페이스를 변경하지 않을 것이기 때문에 반대입니다( dehoistDependencies ).

내가 이것에 대해 좋아하지 않는 것은 그것이 기술적 동작(호이스팅)을 취하고 그것을 의미론적 동작으로 바꾸려고 한다는 것입니다. 사용자 스토리에 초점을 맞춘 다음 그 반대가 아닌 구현을 파악해야 합니다.

이 경우 사용 사례("특정 패키지에만 종속성 설치")를 확장하면 yarn --focus 가 더 잘 해결될 것이라고 생각합니다.

핵심 질문은 호이스팅과 단일 yarn.lock 파일이 작업 공간에 엄격하게 필요한지 여부입니다. 내 말은, 그것이 진정으로 그들을 정의하는 것입니까 아니면 역사적으로 그들이 얻은 첫 번째 기능인 "그냥"입니까?

예를 들어, 우리의 사용 사례에서 작업 공간의 최상의 가상 동작은 다음과 같습니다.

• 효율성을 위해 개발 시 node_modules 를 호이스트합니다.
• 빌드를 위해 로컬 yarn.lock 파일을 유지하고(다른 사람들이 이 스레드에서 언급한 특정 패키지를 Docker에서 빌드합니다) 또한 패키지가 특정 버전을 잠글 수 있도록 합니다. #6563도 참조하십시오.
• 호이스팅이 필요하지 않거나 피해야 하는 경우에도 yarn workspaces run <script> 를 통해 스크립트를 실행합니다.

호이스팅은 nohoist 로 비활성화할 수 있으며 run 는 명령을 사용하지 않음으로써 "비활성화"할 수 있지만 단일 yarn.lock 파일을 "비활성화"하는 것은 불가능합니다. 비활성화할 수 없는 핵심 기능인지 또는 아직 충분히 요청되지 않은 것인지 확실하지 않습니다. :)

이 문제를 해결하는 가장 좋은 방법은 yarn install --app-mode package@version

그렇게 하면 특정 버전에서 앱을 게시할 때 작업 공간 잠금 파일을 복사하기만 하면 되고 app-mode 설치하면 번들 잠금 파일을 준수합니다.

Yarn은 전체 잠금 파일을 설치할 필요가 없습니다. 해당 패키지와 관련된 종속성 그래프의 일부만 쉽게 추출할 수 있어야 합니다.

사실 이것은 지금도 수동으로 수행하는 것이 상당히 쉬울 수 있습니다.

• 레지스트리에서 패키지 zip을 직접 다운로드합니다(yarn에는 이에 상응하는 것이 없고 npm은 npm pack package@version ).
• node_modules/package에 gzip 압축을 풉니다.
• node_modules/package로 cd
• 거기 에서 yarn install --production 을 실행하십시오(번들 잠금 파일을 존중할 것입니다).

편집: 불행히도 작업 공간 잠금 파일에는 앱 패키지의 종속성일 수 있는 작업 공간 내의 패키지 버전이 포함되어 있지 않기 때문에 이것은 모두 잘못된 것입니다. 작업 공간 잠금 파일에서 앱 잠금 파일을 만들 때 복사보다 더 복잡한 작업이 필요합니다.

별도의 잠금 파일이 답인지 확실하지 않지만 비슷한 문제가 있습니다. CLI와 백엔드를 사용하여 monorepo를 설정했습니다. CLI에는 특정 설정이 있는 데스크톱 시스템에서만 작동하는 플랫폼별 패키지가 몇 개 필요합니다. 반면에 현재 작업 공간 구현에서는 근본적으로 불가능한 도커 이미지로 API를 빌드할 수 있어야 합니다.

@samuela 와 매우 유사한 사용 사례입니다! 이것은 큰 도움이 될 것입니다!

내 사용 사례는 다른 "실제" 사례에 비해 웃기게 보일 수 있습니다. 그러나 일부 유틸리티에 대한 monorepo가 ​​있습니다. 이 경우에는 반응 후크가 packages/* 있습니다.

packages/* 옆에 두 번째 작업 공간이 있습니다. local/* 입니다. 이것은 실제로 gitignore에 있으며, 아이디어는 회사의 개발자가 거기에서 원하는 모든 것을 할 수 있다는 것입니다. 예를 들어 create-react-app 앱을 거기에 넣고 개발 중에 후크를 테스트할 수 있습니다.

이제 local/* 패키지가 gitignore에 있지만 루트 yarn.lock 는 로컬 작업 공간으로 인해 단순히 부풀려지고 오염되어 git에 체크인됩니다.

내가 원하는 것은 일부 작업 공간이 다음과 같은 매핑과 같은 특정 잠금 파일을 사용하도록 지정하는 방법입니다.

  "workspaces": {
    "packages": [
      "packages/*",
      "local/*"
    ],
    "lockfiles": {
      "local/*": "./local.yarn.lock"
    }
  }

또는 "_이_ 작업 공간에서 잠금 파일에 아무것도 넣지 마십시오"를 지정하는 방법도 있습니다.

그러나 예, 내 것은 처음부터 심각한 사용 사례가 아닙니다. :)

별도의 잠금 파일이 답인지 확실하지 않지만 비슷한 문제가 있습니다. CLI와 백엔드를 사용하여 monorepo를 설정했습니다. CLI에는 특정 설정이 있는 데스크톱 시스템에서만 작동하는 플랫폼별 패키지가 몇 개 필요합니다. 반면에 현재 작업 공간 구현에서는 근본적으로 불가능한 도커 이미지로 API를 빌드할 수 있어야 합니다.

당신은 그것을 못 박았습니다. 내가 보기에, yarn.lock 파일의 가장 핵심적인 이점 중 하나는 frozen-dep 프로덕션 빌드를 만드는 것입니다! Yarn의 제작자는 그것을 잊었습니까?

단일 잠금 파일 문제를 해결하기 위한 또 다른 주장은 코드 소유권입니다. GitHub CODEOWNERS 기능과 같은 것을 사용하는 단일 저장소가 있는 경우 패키지에 대한 완전한 소유권을 개발자 그룹에 제공할 수 없습니다. 자신의 작업 공간에 무언가를 설치하면 항상 루트 수준 잠금 파일이 변경되기 때문입니다. 이 변경은 잠금 파일의 코드 소유자의 승인을 받아야 하며, 충분한 규모의 단일 저장소가 주어지면 원래 작업 공간의 소유자와 다릅니다.

작업 공간별 잠금 파일을 생성하는 옵션이 있는 또 다른 이유: Google App Engine은 잠금 파일(NPM/Yarn) 없이 노드 서비스 시작을 거부합니다. 이것은 그들 입장에서 훌륭한 devop이지만 우리에게는 고통입니다. 지금까지 우리가 가진 옵션은 다음과 같습니다.

• 우리가 의미하는 서비스를 나타내는 env vars로 모두 배포하고 env vars를 기반으로 분기하도록 yarn start (유일하게 지원되는 진입점)를 수정합니다.
• 빌드 스크립트가 기본 잠금 파일을 각 작업 공간에 복사하고 관심 있는 서비스만 배포하도록 합니다. (@johannes-scharlach에게 감사드립니다.)

궁극적으로 작업 공간 잠금 파일별로 생성된 yarn install --workspace-lockfile 명령이 최상의 솔루션이 될 것이라고 생각합니다.

패키지 수준 잠금 파일에 대한 옵션이 있으면 우리에게도 도움이 될 것입니다. 우리의 사용 사례는 약간 다릅니다. 로컬 종속성을 관리하는 새로운 방법을 시도하고 있습니다.

그래서 우리는 이미 모노 리포지토리를 가지고 있고 단일 패키지만 포함하는 리포지토리도 있습니다. 이것들은 모두 게시되어 함께 사용할 수 있지만 로컬에서 심볼릭 링크로 연결하면 매우 유용할 때가 많습니다.

그러나 일부 개발자는 심볼릭 링크 등을 관리하는 데 어려움을 겪기 때문에 우리는 모두 우리 컴퓨터에 복제하는 표준 빈 원사 작업 공간 모노 리포지토리를 시도하고 패키지 리포지토리를 로컬 모노 리포지토리로 복제합니다. 우리 중 일부는 하나의 패키지 복제본을 가질 수 있고 일부는 5개를 가질 수 있습니다. 이것은 매우 편리하고 로컬, 교차 리포지토리, 교차 종속성 개발을 절대적으로 쉽게 만듭니다.

그러나 우리는 해결할 수 없는 한 가지 문제를 발견했습니다. 종속성을 편집해도 로컬 원사 잠금 파일이 업데이트되지 않고 항상 업데이트 종속성을 업데이트하지 않는 빈 모노 리포지토리의 루트 파일이 업데이트됩니다(모든 항목이 다음 아래에 있습니다. /packages gitignore.

모노 리포지토리 루트에 대한 잠금 파일 쓰기를 호이스트하지 않는 옵션이 있으면 훌륭하고 패키지 수준에서 작성하도록 할 수 있습니다.

참고로 저는 다른 사람들이 언급한 Docker와 관련된 배포 및 빌드 문제를 발견했으며 이것도 해결할 수 있습니다!

이 기능은 저에게도 매우 유용할 것입니다. 제 경우에는 일부 패키지가 다른 플랫폼에 배포된 단일 저장소가 있습니다. 하나는 Now.sh와 함께 배포된 Next.js 앱이고 다른 하나는 Firebase에 배포된 클라우드 기능 모음입니다.

이 두 배포 모두에서 소스 코드가 번들로 제공되고 클라우드에 설치 및 빌드할 수 있도록 업로드됩니다. 소스와 함께 사용할 yarn.lock 파일이 없다는 것은 종속성이 package.json의 버전을 사용하여 설치되고 잠긴 버전이 없음을 의미합니다.

또한 각 작업 공간에서 yarn.lock 파일을 활성화할 수 있기를 바랍니다.

저는 원사 작업 공간이 주로 monorepos를 위한 것임을 알고 있지만 @LeeCheneler 와 매우 유사한 경우 우리의 사용 사례가 있습니다.

기본적으로 다른 프로젝트(모두 자체 저장소가 있음)에서 종속성으로 사용하는 React 구성 요소 라이브러리를 만들었습니다. 원사 작업 공간을 사용하여 구성 요소 라이브러리의 로컬 버전을 쉽게 참조하고 변경 사항을 다른 프로젝트의 로컬 버전에 빠르게 전파할 수 있습니다. 또한 library: "*" 종속성이 변경 없이 작동하기 때문에 프로덕션으로 푸시할 때 package.json을 수정할 필요가 없습니다. 우리의 유일한 문제는 원사 잠금 파일이 없으면 각 프로젝트의 프로덕션 버전이 다른 패키지 버전을 사용하게 될 수 있다는 것입니다.

이 문제는 yarn 작업 공간을 사용하는 모든 패키지 개발자에게 공통적일 것이라고 상상해야 합니다.

최상위 잠금 파일의 또 다른 중요한 문제는 Docker의 계층 캐싱을 중단한다는 것입니다. 일반적으로 먼저 package.json 및 yarn.lock을 복사하여 Docker 캐싱을 최적화할 수 있습니다. Docker가 해당 파일에 변경 사항이 없으면 이전 계층을 사용합니다. 그러나 해당 잠금 파일이 전체 모노리포지토리에 대한 단일 파일인 경우 패키지가 변경되면 캐시가 무효화됩니다. 우리에게 이것은 캐시 없이 모든 패키지가 빌드되는 엄청나게 느린 CI/CD 파이프라인을 초래합니다. 특정 스크립트를 실행하기 위해 패키지 변경 사항을 확인하는 Lerna와 같은 다른 도구가 있습니다. 이것은 또한 잠금 파일의 종속성 변경이 최상위 수준에 있기 때문에 선택되지 않을 수 있기 때문에 중단됩니다.

이 (약간 오래된) 문제를 제기해서 유감이지만 이것이 도움이 될 사용 사례도 있습니다. 독립적으로 호스팅되고 개발된 10개 정도의 마이크로 서비스가 있지만 yarn install 를 입력하여 모든 폴더에 종속성을 설치한 다음 yarn start 를 실행할 수 있는 중앙 작업 공간 저장소가 있으면 좋을 것입니다. 모든 마이크로 서비스를 시작하는 스크립트를 실행합니다. 이것은 비교적 간단한 스크립트로 수행할 수 있는 작업이지만 yarn 작업 공간으로도 수행할 수 있는 것처럼 보였지만 각 micorservice의 yarn.locks를 존중하면서 작동하도록 할 수 없었습니다.

@nahtnam Yarn 1.x monorepo의 아이디어는 조금 다르다고 생각합니다. 한 지붕 아래의 독립적인 프로젝트가 아니라 일부 구성 요소가 노출된 단일 대형 프로젝트(작업 공간이라고 함)에 관한 것입니다. 이러한 구성 요소는 완전히 독립적이지 않지만 다음과 같이 사용할 수 있습니다. Babel 컴파일러는 하나의 더 큰 엔터티로, preset-env 는 하위 모듈로 사용할 수 있습니다. 또한 종속성이 통합된다는 점에서 동질적입니다. 일부 패키지가 core-js 에 의존하는 경우 모든 단일 패키지에서 동일한 core-js 버전이어야 합니다. 단일 루트 잠금 파일로 다른 버전을 잠그거나 프로젝트의 일부가 다른 버전에 의존하는 것은 의미가 없습니다. 그리고 하나의 프로젝트이기 때문에 모든 구성 요소가 자동으로 루트 node_modules 에 연결됩니다. 이는 완전히 독립적인 프로젝트에서는 이상합니다.

따라서 마이크로 서비스 팩을 개발하는 경우(독립적이며 일부는 몇 년 동안 건드리지 않고 다른 일부는 생성/업데이트되며 다른 팀에서 개발할 수 있음) 루트가 없는 개인 잠금 파일이 있어야 합니다. 잠금 (Docker 문제도 여기에 있습니다). 유일한 질문은 스크립트 실행에 어떤 도구가 도움이 될 것인지입니다. Lerna는 Yarn에 묶여 있지 않기 때문에 답이 될 수 있습니다.

유일한 질문은 스크립트 실행에 어떤 도구가 도움이 될 것인지입니다. Lerna는 Yarn에 묶여 있지 않기 때문에 답이 될 수 있습니다.

@the-spyke 그뿐만이 아닙니다. yarn workspaces 도 npm link 와 같은 방식으로 개발용 모듈을 연결하여 해결합니다. 이것이 우리가 이것을 사용하는 주된 이유입니다. npm link 는 어떤 경우에는 잘 작동하지 않습니다.

@spyke 감사합니다! 어떤 이유에서인지 뒤집힌 줄 알았습니다(lerna 대 yarn 작업 공간). 나는 lerna를 조사했고 그것이 내 문제를 해결하는 것처럼 보입니다.

내가 작업하는 모든 단일 프로젝트에 대해 작업 공간을 사용하게 되었습니다. 왜냐하면 필요할 때 업데이트할 수 있는 별도의 utilities 패키지를 갖는 것이 얼마나 쉬운지, 그리고 일부 패키지를 분기하고 싶을 때(본질적으로 내가 들어본 적이 없는 동시에 두 개의 분기에서 작업할 수 있도록 허용함), 내 utilities 의 패키지를 사용하고 싶을 때마다 종속성을 다시 설치할 필요가 없습니다. package.json 에 추가하지 않고 바로 사용할 수 있습니다. 자동 IDE 가져오기의 경우) ; 모든 것이 작동합니다. @the-spyke는 좋은 지적을 하고 있습니다. 아마도 independent projects under one roof 는 작업 공간의 목적이 아닐 수 있지만 이것이 제가 여기서 하고 있는 일입니다. monorepo-base 저장소가 하나 있습니다. packages 폴더는 제외 되지만 packages 아래의 각 폴더는 별도의 독립적인 git repo입니다.

물론 이것은 저를 이 스레드의 주제로 안내합니다. 모든 패키지를 하나의 repo로 커밋하지 않기 때문에 루트 수준 yarn.lock 는 의미가 없습니다. 나는 모든 것을 설치하기 위해 --no-lockfile 를 사용해 왔으며 최근에 class-validator 의 충돌하는 버전에 문제가 생겼습니다. 지금은 모든 dep를 특정 버전으로 잠그고(솔직히 그 수준의 제어가 나에게 더 이해가 됨) 작동 방식을 확인합니다. 나는 전체 트레드를 다시 읽을 것입니다. 아마도 제 사용 사례에 사용할 수 있는 몇 가지 팁이 있을 것입니다.

추신.
yarn why 는 lockfile 없이는 작동하지 않으며 일부 사람들이 App Engine의 문제를 언급하는 것을 보았습니다. 모든 패키지가 별도의 저장소인 경우(VCS에 추가하지 않고) 설치할 때마다 잠금 파일이 생성될 수 있다고 가정합니다. 그 구체적인 경우에 대해서는 확실하지 않습니다.

불행히도 @johannes-scharlach가 제안한 솔루션은 빌드된 이미지에 일부 빌드 폴더에 포함되지 않은 런타임 노드 모듈이 필요한 경우 매우 지저분해집니다. 최종 빌드 단계.

(주제에서 약간 벗어남 )

다음은 기존 Docker 워크플로에 대한 영향을 최소화하면서 도달한 솔루션입니다.

1. ln project/yarn.lock packages/package1/yarn.lock - 루트 yarn.lock 에서 각 패키지로 하드 심볼릭 링크를 만듭니다.
2. 추가 COPY yarn.lock . 각각 packages/package1/Dockerfile
3. yarn install Docker 내부

장점 :

• 전체 모노레포를 이미지 레이어에 복사할 필요가 없습니다.
• 패키지 수준 Dockerfile을 루트에서 단일 Dockerfile로 병합할 필요가 없습니다.
• 기본적으로 작업 공간 잠금 파일의 요구 사항을 충족합니다.

단점 :

• --frozen-lockfile 이(가) 작동하지 않습니다. 작업 공간 패키지는 yarn.lock 포함되어 있지 않으므로 yarn은 yarn.lock 존재하지 않는 package.json "추가한" 패키지를 봅니다.

CI/CD 파이프라인의 첫 번째 단계로 yarn --frozen-lockfile 를 수행하여 이를 피할 수 있으므로 이는 상관없이 사소한 단점입니다.

편집하다:
제 생각에는 설치에 대한 원사 문서가 패키지 해결 프로세스에서 잠금 파일을 사용하는 방법에 대해 조금 더 명확할 수 있다고 생각합니다.

편집하다:
따라서 git은 실제로 하드 링크를 지원하지 않고 소프트 심볼릭 링크만 지원하므로 이 전략은 작동하지 않습니다.

또 다른 대안은 사전 커밋 githook을 사용하여 yarn.lock 를 각 작업 공간에 복사하는 것입니다... 로컬 컴퓨터에서 배포할 때 여전히 문제를 허용하므로 이상적이지 않습니다.

@dan-cooke 통찰력을 주셔서 감사합니다. 감사합니다!

@dan-cooke, 작업 공간의 새로운 종속성이 모든 Dockerfile에 대한 설치 계층을 무효화하기 때문에 이것은 Docker의 계층 캐싱을 중단합니다.

@migueller 설치 계층이 변경되지 않아야 하는 경우 모든 패키지에 대해 하나의 잠금 파일을 사용해서는 안 됩니다. 종속성을 하나의 거대한 목록으로 병합하고 끌어올리는 것이 Workspaces의 전체 목적입니다. Docker 캐시를 "중단"하는 것과는 달리 실제 종속성이 package.json 지정되지 않았기 때문에 캐시가 무효화되므로 패키지의 최종 코드는 yarn.lock 의 내용에 따라 달라집니다. 결과적으로 yarn.lock 모든 변경 사항에 대해 모든 패키지를 다시 빌드해야 하며 Docker는 모든 것을 올바르게 수행합니다. 그리고 모든 빌드가 yarn install 레이어를 재사용할 수 있기 때문에 where every package is built without the cache 와 같지 않습니다(아마도 이것을 설정해야 할 것입니다).

@migueller
옳은. 다행스럽게도 새 종속성을 자주 추가하지 않으므로 최대 한 번 스프린트에만 문제가 될 것입니다.

그럼에도 불구하고 Docker에서 재현 가능한 종속성을 위해 (우리를 위해) 지불해야 하는 적은 비용입니다.

@the-spyke, 참으로. 이것이 이 문제가 패키지당 개별 잠금 파일을 갖는 것과 관련된 이유입니다. 이런 식으로 캐시된 계층은 패키지의 종속성이 변경되고 다른 패키지와 독립적일 때만 무효화됩니다.

이 토론을 v7.0부터 작업 공간도 지원하는 npm 자체로 옮기는 것도 가치가 있습니다.

나는 관련 주제를 조사해 왔으며 위의 내 의견 에 약간의 설명을 추가하고 싶습니다(주로 경험이 덜한 개발자를 대상으로 한다고 생각합니다. 내가 직면한 문제는 lockfile 의 중요성을 이해하는 데 실패했기 때문입니다.

"특정 버전에 대한 모든 종속성을 잠금"고정라고; 불행히도, 내가 고려하지 않은 하위 종속성 업데이트( 여기 기사의 마지막 단락)가 잠재적으로 중단되는 것을 방지하지 못합니다. 이것이 바로 lockfile이 발생하는 것을 방지하기 위한 것입니다.

나는 과거에 여러 번 업데이트를 깨는 데 충분한 시간 이상을 낭비했습니다. 나는 사소한 업데이트로 인한 보이지 않는 버그보다 병합 충돌과 조직적 골칫거리를 처리하기를 원하기 때문에 monorepo에서 lockfile 를 사용하여 실험할 것입니다.

위에서 말했듯이 이 문제에 대한 진전이 있기를 매우 기대하고 있습니다.

@migueller 개별 잠금 파일은 개별 Yarn Monorepos를 의미합니다. Monorepo에서 deps 균일성을 깨뜨리기 때문에 Workspace에 대한 잠금 파일을 가질 수 없습니다. 그렇게 하려면 Yarn Monorepo의 원래 아이디어에서 벗어나는 것입니다. 다른 작업 공간에서 다른 버전(또는 전체 하위 트리)을 사용하는 대신 루트에서 deps를 단일 목록으로 통합, 호이스팅 및 축소하는 것입니다. .

@the-spyke 그러나 원래 문제는 정확히 그 반대입니다. 작업 공간당 잠금 파일입니다.

작업 공간마다 잠금 파일을 가질 수 없다는 것을 이해하지 못합니다.

Monorepo에서 dep 균일성을 깨뜨립니까? 물론 개발을 위해. 그러나 각 작업 공간에서 가벼운 마이크로 서비스를 배포해야 하는 경우 공유 종속성의 전체 목적이 사라집니다.

공유되고 호이스트된 deps는 개발 시에만 의미가 있습니다.

작업 공간이 Docker에서 작동하려면 잠금 파일이 필요합니다.

@dan-cooke 보시다시피 2018년에도 이 문제가 있었지만 지금은 생각이 다릅니다.

Docker와 Microservices를 말하는 것입니다. 하지만 일반 npm 패키지를 개발하면 어떻게 될까요? 내 dependencies 사양에 따라 최종 사용자가 제공할 것이기 때문에 고정할 production 종속성 하위 트리가 없습니다. 그래서 제가 원하는 것은 개발 경험을 극대화하고 Monorepos와 Yarn Workspaces가 완벽하게 수행하는 것입니다.

동시에 마이크로서비스(MS)를 개발하는 경우 두 가지 가능한 상황이 있습니다.

1. 독립 프로젝트. 일부 MS는 개발 ​​중이고 일부는 몇 년 동안 건드리지 않았습니다. 이 경우 그들은 완전히 독립적입니다. 이있을 수있다 UserService 사용 [email protected] 및 MessagesService 사용하여 [email protected] . Workspaces의 폴더를 node_modules 루트로 연결하는 것은 그리 쉬운 일이 아닙니다. 따라서 루트 잠금 파일을 갖는 것은 의미가 없습니다. 별도의 파일(루트)을 생성하여 독립적으로 관리합니다. Yarn 문서에서 Multirepo 라고 합니다. 그러나 이제 당신이 말하는 것은 "편의를 위해 루트 폴더와 다른 폴더에서 작업을 실행하고 싶습니다"입니다. 그리고 그것은 완전히 다른 주제입니다.

2. Jest/Babel/etc와 같은 통합 종속성을 가진 프로젝트. 이것이 작업 공간이 만들어진 이유이지만 MS에는 추가 요구 사항이 있습니다. Linting 및 테스트와 같은 CI 단계에서는 개발자 시스템에서와 동일하게 작동하기 때문에 모두 잘 작동합니다. Yarn이 루트 node_modules에 설치하고 평면화한 deps. 추가로 yarn install 단계를 캐시하여 동시 빌드 속도를 높일 수 있습니다.

   프로덕션에서는 완전히 다릅니다. 하나의 작업 공간에만 deps가 필요하고 utils 패키지를 설치하는 방법으로 끝납니다. 링크하거나 tarball로 다운로드해야 합니까? 따라서 실제로 필요한 것은 작업 공간당 잠금 파일이 아니라 작업 공간을 지정하여 실행할 수 있는 yarn install --prod <workspace> 와 같은 명령이 있고 프로덕션 dep만 설치하고 동시에 참조되지 않은 다른 작업 공간은 무시하는 것입니다. 내 data WS가 utils WS에 의존하지만 logging WS에는 의존하지 않는 경우 logging 자체 및 해당 deps가 node_modules 나타나지 않아야 합니다.

   빌드 패키지를 저장소(npm, Arifactory, GutHub)에 게시하는 경우 잠금 파일을 작업 공간에 복사하고 여기에서 yarn install --prod 수행하면 유사한 동작을 얻을 수 있습니다. 오래된 파일에 대해 경고해야 하지만 새 버전으로 처음부터 다시 만드는 대신 파일에서 과도한 deps를 제거해야 합니다(방금 시도하고 합법적으로 보입니다). Offline Mirror를 사용하면 훨씬 더 좋고 강력해야 합니다.

   그리고 결국 Multirepos를 위해 정확히 구현된 Focused Workspaces를 갖게 되었습니다.

그래서 내가 말한 것은 문제가 그것이 무엇인지 같지 않을 수도 있다는 것입니다.

@the-스파이크
나는 당신이 말하는 것을 본다. 나는 그것이 이 결과가 어떻게 달성되는지에 따라 결정된다고 생각합니다. 작업 공간당 잠금 파일은 실제로 원하는 결과를 얻는 가장 좋은 방법이 아닐 수 있습니다. 당신은 몇 가지 좋은 포인트를 확인합니다.

어쨌든 "모든 사람에게 맞는" 솔루션이 아닙니다.

@spyke님, 좋은 점을 말씀해 주십시오. Yarn 작업 공간이 해결하기 위해 설계된 문제와 대규모 단일 저장소를 관리하는 데 사용하는 것이 해당 디자인과 일치하는지에 대해 더 많은 생각을 해야 합니다.

다음과 같은 시나리오를 어떻게 해결할지 궁금합니다.

.
└── packages
    ├── app1
    ├── app2
    ├── lib1
    ├── lib2
    └── lib3

lib3 는 공유 라이브러리이며 app1 및 app2 종속됩니다. lib1 는 app1 에서만 사용되고 lib2 는 app2 에서만 사용됩니다. 귀하의 제안에 따라 lib1 및 app1 는 자체 잠금 파일이 있는 자체 작업 공간에 있어야 하며 lib2 및 app2 와 동일해야 합니다. 이제 문제는 무엇을하는 것입니다 lib3 _both_ 경우 app1 및 app2 에 의존? 두 작업 공간( app1 및 app2 )이 작업 공간에 lib3 를 추가한 다음 각 앱에서 yarn install 를 실행하도록 만들 수 있습니까? Yarn이 이것을 허용합니까? app1 및 app2 를 모두 로컬에서 개발하려는 경우 충돌이 발생합니까? (아마도 app1 는 React 앱이고 app2 는 GraphQL API임) ? 작동할 수 있을 것 같습니다.

다음 질문은 "이 방법으로 호이스팅의 이점을 어떻게 얻을 수 있습니까?"입니다. 예를 들어, app1 와 app2 가 많은 공통 의존성을 공유한다면 그것들을 끌어올리는 것이 좋을 것입니다. 그러나 이것이 어떻게 범위를 벗어날 수 있는지 볼 수 있으며 Yarn PnP가 해결해야 할 문제입니다(파일을 node_modules에 복사하지 않고 대신 공유 캐시를 가짐).

나는 이것을 시도하고 다시보고 할 것입니다. 이것이 작동하면 아마도 우리는 Yarn 작업 공간을 계속 잘못 사용했을 것입니다...

편집: 나는 그것을 시도했고 작동합니다.

저는 지금 입장을 바꿨고 Yarn 작업 공간으로 전체 모노레포를 관리할 때 작업 공간당 개별 잠금 파일을 갖는 것이 가장 먼저 마음에 떠오를 수 있지만 올바른 질문이 아닐 수도 있음을 깨달았습니다. 더 나은 질문은 "Yarn 작업 공간이 단일 저장소를 관리하도록 설계되었습니까?"입니다. 대답은 평소와 같이 "그것에 달려 있습니다"입니다.

당신이 Babel이고 단일 팀이 단일 저장소에서 작업하고 있고 모든 것이 잠금 단계에 따라 변경될 예정이라면 그렇습니다. Yarn 작업 공간이 설계된 이유입니다. 그러나 여러 팀이 있는 조직이고 단일 저장소를 사용하는 경우 단일 Yarn 작업 공간 루트로 전체 단일 저장소를 관리하고 싶지 않을 것입니다. 모노레포 내에서 Yarn의 기본 동작이나 여러 Yarn 작업 공간 루트를 사용하고 싶을 것입니다. 이것은 어떤 앱을 만들고 있는지, 몇 팀이 있는지 등에 따라 결정됩니다.

우리에게는 배포 가능한 각 엔터티(이 경우 Dockerfile이 있음)에 대해 각 엔터티에 대해 별도의 yarn install 수행되기를 원한다는 것이 분명해졌습니다(이것이 작업 환경 루트인지 여부에 관계없이). 이것은 코드 소유권에 대한 명확성을 제공하고, 다른 케이던스에서 발생하는 격리된 배포를 허용하고, 잠금 파일 및 Docker 등의 캐싱 문제를 해결합니다. 하지만 여기에는 몇 가지 단점이 있습니다.

• 중복된 node_modules 패키지는 어떻습니까? 이것은 monorepo의 일반적인 문제 유형이며 Yarn 작업 공간이 호이스팅에 도움이 되지만 일반적인 monorepo 솔루션은 아닙니다. 하지만 다른 솔루션이 있습니다. 예를 들어 Yarn PnP가 이를 처리합니다. Yarn 없이 Lerna를 사용하고 --hoist 옵션을 사용할 수도 있습니다.
• 개발 중에 작업 공간에서 명령을 실행하는 유틸리티는 어떻습니까? 다시 말하지만, Yarn 작업 공간을 사용하면 이 작업을 수행할 수 있지만 그렇다고 해서 전체 모노레포를 Yarn 작업 공간 루트로 만들어야 한다는 의미는 아닙니다. 필요한 도구와 스크립트를 구축하는 것은 각 팀마다 다르며 모노레포에 따라 다릅니다. Yarn 작업 공간은 아마도 monorepo 작업 실행기로 설계되지 않았을 것입니다. 이 작업을 수행하기 위해 Yarn 작업 공간을 약간 구부리려고 할 수도 있지만(예: yarn workspace ... 사용하여 단일 저장소에서 NPM 스크립트 실행) 전체 단일 저장소에 대한 단일 작업 공간 루트는 아마도 그렇지 않을 것이라는 점을 명심하는 것이 중요합니다. Babel, Jest, React 등이 아닌 한 필요한 것을 제공합니다.

모노레포를 실행하는 데는 전혀 다른 문제가 있습니다. 예를 들어 종속성을 추적하고 CI에서 시간을 절약하기 위해 변경된 항목만 다시 작성하는 것은 어떻습니까? Yarn 작업 공간은 종속성 그래프를 쿼리할 수 있도록 하여 도움이 될 수 있습니다. 예를 들어 Lerna는 실행 중인 명령의 토폴로지 정렬을 허용하기 위해 이 작업을 수행합니다. Yarn v2를 사용하면 실제로 종속성 그래프도 쿼리할 수 있습니다. 패키지 관리자 PNPM도 이 작업을 수행합니다. 그러나 모노레포의 복잡성에 따라 Bazel , Pants , Buck 등과 같은 (패키지 관리자가 아닌) 빌드된 도구를 시도하고 싶을 수도 있습니다.

@migueller 귀하의 요구 사항에 따르면 엄격하게 독립적인 패키지나 기타 이국적인 것이 필요하지 않으며 더 얇은 개발자 설치도 원합니다. 이러한 경우 일반 Yarn Monorepo: 단일 루트 및 모든 패키지를 작업 공간으로 시작해야 합니다. 설치 시간이 빨라지고 디스크 사용량이 줄어들며 app1 는 로컬 링크 lib1 및 lib3 합니다. 유일한 단점은 lib1 devDep을 추가하면 공유 yarn.lock 가 업데이트되기 때문에 CI 캐시 무효화가 더 자주 발생한다는 것입니다. 그러나 일반적으로 이 절충안을 많이 걱정하기 위해 종속성을 업데이트하지 않습니다.

lib1 는 lodash@^4.5.0" and lib2 may depend on lodash@^4.10.0"에 따라 달라질 수 있습니다. Monorepo의 경우 lodash 의 단일 버전이 사용되기를 원하므로 Yarn은 루트 node_modules에 올려진 ` [email protected] "와 같은 두 지정자와 호환되는 최신 버전을 설치합니다. 그리고 업데이트의 경우 단일 통합 버전을 업데이트하므로 모든 작업 공간이 항상 같은 페이지에 유지됩니다. 이것은 원하는 동작입니다.

독립적인 팀이 독립적인 프로젝트를 개발하는 상황도 있습니다. 이 경우 proj1 는 proj2 에 [email protected] 있는 [email protected] 에 머물고 자신의 케이던스로 업데이트할 수 있습니다. 물론 lodash@~4.5.0 와 같은 보다 엄격한 지정자를 사용하여 이를 달성할 수 있지만 여전히 2단계 종속성을 너무 일찍 업데이트할 수 있습니다. 따라서 전체적으로 해당 프로젝트는 완전히 관련이 없을 수 있으며 하나의 git repo 내부에서 발생했습니다. 이 경우 Yarn Monorepo로 바인딩하고 공유 잠금 파일에 대한 독립성을 절충할 이유가 없습니다. 그냥 있는 그대로 대하세요. 독립적인 삶이 있는 별도의 프로젝트입니다. 그리고 그것을 Multirepo라고 합니다. Unix에서 모든 디렉토리는 / 에 있지만 PC에서 가능한 모든 JS 프로젝트가 Monorepo여야 한다는 의미는 아닙니다 :-)

프로덕션 사용을 위해 가능한 최소한의 Docker 이미지를 빌드하는 것은 Yarn과 완전히 관련이 없지만 Yarn이 yarn.lock 라는 개발 아티팩트를 재사용하도록 강제할 수 있으며 이 작업도 도움이 될 수 있습니다.

@the-spyke, 이 예에서는 3개의 작업 영역만 사용했지만 실제 저장소에는 프론트엔드와 백엔드 모두에 대해 라이브러리와 배포된 워크로드가 조합된 20개 이상의 작업 영역이 있습니다. 내가 지금 보는 방식은 독립적인 잠금 파일이 있는 여러 Yarn 작업 공간 루트를 갖는 것이 아마도 의미가 있을 수 있는 monorepo(또는 multirepo라고 하는 것)가 있다는 것입니다. 우리는 분리 단위로 전개 가능한 단위를 사용하는 것을 생각하고 있습니다. 잠금 파일과 잘 정렬됩니다.

제 생각에는 이 작업이 매우 훌륭하게 작동하는 이유는 초기 블로그 게시물에 달리 명시되어 있음에도 불구하고 Yarn 작업 영역이 작업 영역 루트 외부의 경로를 지원한다는 사실입니다. 예를 들어 다음을 가질 수 있습니다.

{
  "workspaces": [
    "../lib1",
    "../lib3"
  ]
}

@migueller 와 동일한 사용 사례가 있으며 한 가지 가능한 아이디어는 Yarn이 다음과 같이 여러 작업 공간 세트 를 지원하는 것입니다.

{
  "workspaces": {
    "frontend-app": ["frontend", "common"],
    "backend-app": ["backend", "common"]
  }
}

Yarn은 두 개의 추가 잠금 파일을 유지 관리합니다(기본 yarn.lock 가 여전히 존재한다고 가정합니다).

.
└── monorepo/
    ├── yarn.frontend-app.lock
    ├── yarn.backend-app.lock
    └── packages/
        ├── frontend
        ├── backend
        └── common

프론트엔드용 Docker 이미지를 빌드할 때 다음을 포함하는 컨텍스트(예: tar 를 통해 )를 생성합니다.

.
└── <Docker build context>/
    ├── yarn.frontend-app.lock
    └── packages/
        ├── frontend
        └── common

내가 깊이 생각하지 않은 것은 프론트엔드와 백엔드가 다른 버전을 잠그면 올바른 버전의 종속성을 설치할 수 있는지( node_modules 링크)입니다. 그러나 순전히 높은 수준의 관점에서 보면 2차원 Yarn 작업 공간이 아마도 우리가 추구하는 것입니다.

( 여기에도 비슷한 글이 올라

작업 공간당 잠금 파일이 필요하지 않고 대신 배포를 위해 작업 공간당 node_modules가 필요한 것 같습니다.

@gfortaine , 토론을 읽으면 실제로 그렇지 않다는 것을 알게 될 것입니다. 별도의 잠금 파일을 갖는 이유는 설치와 관련이 없으며 대신 특정 패키지가 변경될 때만 변경되는 잠금 파일이 있습니다. 최상위 잠금 파일은 _모든_ 작업 공간 종속성이 변경되면 변경되지만 단일 패키지로 범위가 지정된 잠금 파일은 _해당_ 패키지의 종속성이 변경될 때만 변경됩니다.

이것이 사용자 영역에서 수행될 수 있다는 점은 언급할 가치가 있습니다. @yarnpkg/lockfile 패키지를 사용하면 최상위 잠금 파일을 구문 분석할 수 있고 yarn workspaces info 를 사용하면 작업 공간 종속성을 결정할 수 있습니다. 이 정보를 각 작업 공간의 package.json 와 함께 사용하여 작업 공간당 잠금 파일을 생성할 수 있습니다. 그런 다음 저장소에 postinstall 스크립트로 설정하여 개별 잠금 파일을 최상위 수준 파일과 동기화된 상태로 유지할 수 있습니다.

나는 이것을 구축하고 내 발견으로 다시보고 할 수 있습니다.

pnpm: @pnpm/make-dedicated-lockfile 에도 불구하고 이 구현을 방금 찾은 것 같습니다.

도움이 되기를 바랍니다 👍

이 동작(작업 공간당 버전 관리, 각 패키지에 여전히 잠금 파일이 있음)에 대한 나의 필요는 하위 트리가 완전히 다른 저장소로 내보내지는 중첩된 단일 저장소가 있으므로 독립적으로 유지되어야 한다는 것입니다. 지금은 lerna/npm과 일부 사용자 지정 논리를 사용하여 버전을 고르게 만들려고 합니다. 원사(중첩 지원이 있는 곳에서 v2로 추측)가 모든 것을 한 번에 관리할 수 있지만 전역 고정의 올바른 하위 집합을 각각 남겨 둘 수 있다면 좋을 것입니다.

설치 후 스크립트는 잠금 파일을 직접 관리하려고 시도할 수 있습니다. 복잡해 보이지만 어느 쪽이든 좋을 것입니다.