모듈화의 개념부터 Yarn Berry까지

디프만에서 패키지 매니저로 Yarn Berry를 사용하기로 했다. Yarn Berry의 특징을 이해하기 위해, 모듈화와 패키지 매니저의 개념부터 차근차근 짚어보았다. 

🗂 모듈화의 필요성

자바스크립트는 파일을 분리해도 모두 같은 전역 스코프 위에서 실행되므로 전역 스코프를 공유한다. 따라서 모듈화를 위해선, ES6 모듈 문법을 사용해야만 한다. script 태그에 module 타입을 설정하면 자바스크립트 파일을 모듈로 로드할 수 있다. 모듈로 로드한 자바스크립트 파일은 모듈 스코프에 포함된다. 모듈 스코프 내의 자바스크립트 파일은 별도의 독립된 스코프를 가지며, 외부에서는 export한 변수와 함수만 접근할 수 있다.

 

ES6에서는 named export 라는 모듈 문법을 사용한다.

• export 키워드를 사용해 함수, 변수, 클래스를 개별로 외부에 공개할 수 있다.
• default export 키워드를 사용할 경우 import 시에 중괄호를 사용하지 않아도 된다.
• 또한 ES6 모듈은 동적 import, export가 불가능하다. 즉 실행시점에 import/export할 대상을 변경할 수 없다.

export 키워드를 사용하는 경우

// lib.js
export const sayHello = () => {
	console.log('hi');
}

// index.js
import {sayHello} from './lib';

sayHello();

export default 키워드를 사용하는 경우

// lib.js
export default const sayHello = () => {
	console.log('hi');
}

// index.js
import sayHello from './lib';

sayHello();

💁🏻‍♂️ npm과 package.json

등장 배경

만약 script태그로 자바스크립트 파일들을 로드한다면, 필요한 패키지를 의존성에 맞게 일일이 나열해야 하고 각 패키지의 버전을 알맞게 관리해야 한다. 이러한 불편함을 해결하기 위해 npm이 등장했다! npm을 사용하면 이 모든 것들을 package.json으로 관리할 수 있다.

package.json

패키지에 관련된 메타 정보를 담고 있는 파일이다. 가령 CRA로 만든 프로젝트의 package.json은 해당 React App에 대한 모든 정보를 담고 있다. 당연히 앱의 의존성에 대한 정보들도 담고 있다.

 

실제로 CRA 프로젝트를 확인해보면 가장 상위 폴더에 package.json 파일이 있을 뿐 아니라 node_modules 내의 의존성 패키지들에도 각각 package.json 파일이 존재하는 것을 확인할 수 있다.

 

npm install 명령어를 입력하면 package.json에 명시된 모든 의존성 패키지들이 node_modules 폴더에 설치된다. 참고로 node_modules는 항상 .gitignore에 포함되는데, 그 이유는 폴더의 크기가 거대하기 때문이다. 크기가 큰 node_modules는 버전 관리 시스템으로 관리하지 않고, 대신 package.json 파일을 참조해 필요한 패키지를 설치한다.

npm의 문제점

• 비효율적인 의존성 탐색 방식
  node_modules를 사용하는 npm은, 패키지를 찾지 못할 경우 상위 폴더의 node_modules를 계속해서 탐색한다. 이러한 의존성 탐색 방식은 매우 비효율적이다. 또한 파일 시스템에 접근하는 I/O 작업이기 때문에 오랜 시간이 걸린다.
• 패키지 호이스팅으로 인한 유령 의존성(phantom dependency) 문제

🫐 Yarn Berry

Plug’n’Play

Yarn Berry의 Plug’n’Play 전략은 이러한 문제를 해결한다.

 

Yarn Berry는 node_modules 폴더를 생성하지 않는다. 대신 .yarn/cache , .pnp.cjs 를 사용한다.

• .pnp.cjs : 각 패키지의 의존성 정보와, 각 의존성의 위치를 저장한다. 이를 참고하면 비효율적인 node_modules 탐색 없이 원하는 의존성에 바로 접근할 수 있다.
• .yarn/cache : 의존성 패키지들이 zip 형식으로 저장되어 있다. 압축 파일을 사용하기 때문에 node_moduls에 비해 크기가 작다.

또한 PnP는 패키지 호이스팅을 사용하지 않기 때문에, npm과 기존 yarn이 가지고 있던 유령 의존성 문제가 발생하지 않는다.

Zero-Install

위에서 언급했듯 node_modules는 크기가 커 버전 관리 시스템에 올리지 않는다. 따라서 레포지토리를 clone해 앱을 첫 실행하는 경우 npm install 명령어를 통해 의존성을 설치하는 작업이 필요했다. 다른 의존성을 사용하는 브랜치로 변경 시에도 잊지 않고 npm install 을 했어야 했다. 반면 yarn berry는 의존성을 zip 형식으로 저장하기 때문에 크기가 작다. 따라서 의존성들을 버전 관리 시스템으로 관리해도 무방하다. Zero-Install 기능은 바로 이 점을 활용한 기능이다.

 

정리하자면 Zero-Install이란, Yarn Berry에서 의존성을 버전 관리에 포함하는 것을 뜻한다. 의존성들이 github로 관리되고 있기 때문에(github에 올라가 있기 때문에), git clone으로 저장소를 복제했을 때 의존성들이 바로 사용 가능한 상태가 된다. 설치할 필요가 없다. (이를 통해 CI에 소요되는 시간을 크게 단축할 수 있다고 한다. 이 점은 아직 CI를 직접 사용해본 적이 없어서 와닿지는 않는다.)

 

yarn berry 로 관리되고 있는 ahmatda 레포지토리를 확인해보면, 실제로 의존성 zip 파일들이 업로드 되어 있는 것을 확인할 수 있다.

 

다음에 기회가 된다면 pnpm과 yarn berry의 차이에 대해서도 정리 해봐야겠다. 방금 간단히 찾아본 바로는, pnpm에서도 PnP 방식을 사용할 수 있다고 한다(!)

References

https://ui.toast.com/fe-guide/ko_DEPENDENCY-MANAGE

의존성 관리

https://toss.tech/article/node-modules-and-yarn-berry

node_modules로부터 우리를 구원해 줄 Yarn Berry