동료 의존성과 트리 셰이킹

피어 종속성은 라이브러리에 필요하지만 소비자가 제공하기를 기대하는 패키지를 선언합니다. 라이브러리의 package.json에서는 React를 dependencies가 아니라 peerDependencies에 포함해야 합니다. 사용자가 라이브러리를 설치할 때 npm/yarn은 React를 자동으로 설치하지 않습니다. 사용자의 앱에 이미 React가 있으며 라이브러리가 해당 인스턴스를 공유하기 때문입니다.

React가 라이브러리의 dependencies에 포함되어 있으면 npm이 소비자의 React와 함께 두 번째 React 사본을 설치할 수 있습니다. 같은 앱에 React 인스턴스가 두 개 있으면 모든 훅이 "Invalid hook call" 오류와 함께 작동하지 않습니다. React를 피어 종속성으로 선언하면 npm에 "React가 필요하지만 소비자가 이미 사용하는 React를 사용하십시오"라고 알리는 것입니다.

일부 피어는 선택 사항일 수 있습니다. 예를 들어 styled-components와 CSS Modules를 모두 지원하는 라이브러리가 이에 해당합니다. peerDependenciesMeta를 사용하여 선택적 피어를 표시하십시오: { 'styled-components': { optional: true } }. npm은 선택적 피어가 없어도 사용자에게 경고하지 않지만, 선택적 패키지가 설치되면 TypeScript 타입을 제공할 수 있습니다.

package.json의 sideEffects 필드는 라이브러리에서 트리 셰이킹을 안전하게 수행할 수 있는지를 번들러에 알려 줍니다. "sideEffects": false로 설정하면 webpack, Rollup 및 유사한 도구에 라이브러리에서 어떤 모듈을 가져와도 부작용이 발생하지 않는다고 알립니다. 따라서 사용자의 번들에서 사용하지 않는 모든 내보내기를 안전하게 제거할 수 있습니다.

CSS 가져오기는 일반적인 부작용입니다. 가져오기만 해도 페이지에 스타일이 삽입되기 때문입니다. 라이브러리가 CSS 파일을 가져온다면 "sideEffects": ["*.css", "*.scss"]로 설정하여 번들러에 JS 파일은 트리 셰이킹해도 안전하지만 CSS 파일은 가져올 때 항상 포함해야 한다고 알려 주십시오.

트리 셰이킹을 최대한 세밀하게 수행하려면 각 컴포넌트를 자체 파일에서 이름 있는 내보내기로 내보내십시오. index.ts에서 모든 항목을 다시 내보냅니다: export { Button } from './Button'. 소비자가 Button만 가져오면 번들러가 다른 모든 컴포넌트를 제거할 수 있습니다. 다시 내보내기를 사용하는 배럴 파일이 이 패턴을 가능하게 합니다.

bundlejs.com을 사용하여 트리 셰이킹을 테스트하십시오. 가져오기 구문을 붙여 넣으면 실제 번들 크기를 알려 줍니다. size-limit npm 패키지를 사용하면 package.json에 크기 예산을 정의하고 가져오기 크기가 한도를 초과할 때 CI를 실패하게 할 수 있습니다: "size-limit": [{ "path": "dist/index.js", "limit": "10 KB" }].

라이브러리 가져오기에 대한 크기 예산을 설정하십시오. CI에서 npx size-limit을 실행하여 예산을 적용합니다. 시간이 지날수록 번들의 영향이 커진다면 범위가 불필요하게 확장되고 있다는 뜻입니다. 집중된 컴포넌트 라이브러리는 개별 컴포넌트 가져오기를 몇 KB 이하로 유지해야 합니다. 소비자에게 전달되기 전에 회귀가 발생하면 알림을 보내십시오.

배포할 컴포넌트 라이브러리에서는 styled-components와 Emotion을 사용하지 마십시오. 이러한 런타임 CSS-in-JS 솔루션은 소비자가 동일한 라이브러리와 버전을 설치해야 하므로 피어 종속성 충돌을 일으킵니다. 소비자가 Tailwind나 일반 CSS를 사용하더라도 CSS-in-JS 런타임을 번들에 포함해야 합니다. 빌드 시 일반 CSS로 컴파일되는 CSS Modules를 선호하십시오.

CSS Modules는 이를 처리하는 번들러와 함께 사용하면 라이브러리에서도 잘 작동합니다. tsup와 Rollup은 CSS Modules 출력을 범위가 지정된 클래스 이름으로 인라인할 수 있습니다. 소비자는 아무것도 구성할 필요가 없습니다. 스타일의 범위가 이미 지정되어 JS 번들에 포함되거나 가져올 수 있는 별도의 CSS 파일로 제공되기 때문입니다.

자체 개발 도구(tsup, TypeScript, 테스트 라이브러리, Storybook)는 devDependencies에 포함합니다. 이러한 도구는 개발 중에만 필요하며 소비자 설치 시 npm install 대상에서 제외됩니다. React는 peerDependencies(런타임 요구 사항)와 devDependencies(라이브러리를 로컬에서 컴파일하고 테스트하는 데 필요)에 모두 포함합니다.

라이브러리의 package.json에서 "sideEffects": false로 설정하면 번들러에 어떤 의미를 전달하나요?

소비자가 앱의 React 인스턴스를 공유하도록 React를 dependencies가 아닌 peerDependencies에 선언하십시오. sideEffects: false는 라이브러리 전체에서 트리 셰이킹을 가능하게 합니다. CSS 가져오기가 제거되지 않도록 sideEffects: ['*.css']를 사용하십시오. 개별 파일의 이름 있는 내보내기는 트리 셰이킹을 가장 세밀하게 수행할 수 있게 합니다. CI에서 size-limit을 사용하여 크기 예산을 적용하십시오. 피어 종속성 충돌을 피하려면 라이브러리에서는 CSS-in-JS보다 CSS Modules를 선호하십시오.