https://yarnpkg.com/advanced/error-codes
General architecture
yarn은 프로젝트를 구성하는 다양한 base component를 알려주 는 core package(@yarnpkg/core)를 통해 작동한다.
core는 스스로 많은 일을 하지 않는다. 단지 프로젝트를 manage하기 위한 여러 로직을 가지고 있을 뿐이다. 커멘드 라인으로 이 로직을 사용하기 위해서 Yarn은 @yarnpkg/cli를 제공하는데, 이것 역시 큰 기능은 하지 않는다. 하지만 두가지 중요한 일을 하는데, 첫번째는 현재 디렉토리(cwd)를 기준으로 프로젝트를 인스턴스화하고, 두번째로 플러그인 작성자에게 yarn 코드베이스 자체를 수정하지 않고도 외부 로직을 작성할 수 있도록 해준다.
Install architecture
yarn install을 실행하게 되면 다음 스텝을 거친다.
1. "resolution step"
- lockfile에 저장된 항목을 로드하고, 이 데이터와 프로젝트의 현재 상태(메니페스트 파일(aka.package.json)을 읽어서 알아낸다)를 기반으로 core는 어떤 항목이 missing되었는지 찾기 위한 내부 알고리즘을 돌린다.
- 누락된 각 항목에 대해서 core는 Resolver interface를 이용해 플러그인을 쿼리하고 주어진 discriptor(supportsDescriptor),identity(getCandidates), transitive dependency list(resolve)와 일치하는 패키지에 대해서 아는지 묻는다
- 새로운 패키지 메타데이터 리스트를 얻으면, core는 새로 추가된 패키지의 transitive dependency에 대한 새로운 해결 단계를 시작한다
Transitive Dependency?
어떤 아티팩트를 의존성으로 추가하면, 그 아티팩트가 가지고 있는 의존성이 함께 딸려옵니다. 그렇게 ‘딸려온’ 의존성을 Transitive Dependency라고 한다.
아래 의존 관계 트리에서 MyProject ← A이고 A ← X이므로 MyProject ← X의 의존 관계가 생김 출처 - 마지막으로 dependency tree의 모든 패키지 range가 메타데이터로 확인되면, core는 우리가 "virtual package"라고 부르는 것을 만들기 위해 메모리에 트리를 빌드한다. virtual package는 동일한 base package에서 나뉘어진 인스턴스이다. 종속성 트리의 위치에 따라서 그들의 dependency set (종속성 집합)이 바뀌는 peer dependency에 나열된 모든 패키지를 명확히 하기 위해 이를 사용한다.
- resolution이 완료되면, "fetch step"에 들어간다.
- 이제 종속성 트리를 구성하는 정확한 package set을 가지고 있고, 이 리스트를 돌면서 패키지가 어디에서나 찾을 수 있는지 여부를 알기 위해 캐시를 하기위한 요청을 한다. 그렇게 하지 않을 경우 이전단계에서 했던 것처럼 플러그인에게 해당 패키지에대해 알고있는지, 알고있다면 원격에서 가져오도록 요청한다.
- fatcher는 fs를 통한 추상화 계층을 통해 core와 통신한다. 패키지가 다양한 소스에서 올 수 있도록 이 과정을 수행하도록 했다.
