본문으로 건너뛰기

· 약 21분
Dongmin Yu

Node.js의 Vite와 Deno

Node.js는 가장 오래되고 널리 사용되는 런타임이며, Vite는 Node.js 기반의 개발 서버이자 빌드 도구입니다. Deno는 Node.js의 창시자인 라이언 달이 만든 새로운 런타임으로, 보안과 현대적인 표준을 강조합니다. Vite와 Deno는 현재 호환되지 않습니다. Vite는 Node.js에 의존하는 많은 패키지들을 사용하고 있으며, Deno는 Node.js와 다른 모듈 시스템과 API를 가지고 있습니다. 하지만 앞으로 Deno가 npm 패키지들을 지원하게 되면, Vite와 Deno가 함께 작동할 수 있도록 하는 프로젝트들이 진행 중입니다.

References

(1) [Deno] Node.js의 대안!! Deno 알아보기 - Dev. DY (2) "데노 vs. Node.js" JS 런타임 선택 가이드 - ITWorld Korea (3) Vite can support deno runtime? · Issue #109 · vitejs/vite · GitHub (4) vite and deno: an experiment - DEV Community (5) Support Vite · Issue #15427 · denoland/deno · GitHub (6) deno와 node.js 비교 | Swtpumpkin Blog

주목받는 자바스크립트 런타임 환경

자바스크립트 런타임 환경은 자바스크립트 코드를 실행할 수 있는 환경을 말합니다. 브라우저 역시 자바스크립트 런타임 환경 중 하나입니다.

  • React Native: React Native는 모바일 앱 개발을 위한 자바스크립트 런타임 환경입니다. React Native는 네이티브 모듈과 통신하면서 자바스크립트 코드를 실행합니다. React Native의 장점은 웹 개발자가 쉽게 모바일 앱을 만들 수 있다는 것이고, 단점은 성능이나 디버깅이 어렵다는 것입니다.
  • Electron: Electron은 데스크톱 애플리케이션 개발을 위한 자바스크립트 런타임 환경입니다. Electron은 Node.js와 Chromium을 결합하여 웹 기술로 데스크톱 애플리케이션을 만들 수 있게 합니다. Electron의 장점은 크로스 플랫폼 개발이 쉽다는 것이고, 단점은 메모리 사용량이 많다는 것입니다.
  • QuickJS: QuickJS는 가볍고 임베디드 시스템에 적합한 자바스크립트 엔진입니다. QuickJS는 C 언어로 작성되었으며, ES2020 표준을 지원합니다. QuickJS의 장점은 속도가 빠르고 메모리 사용량이 적다는 것이고, 단점은 아직 안정성이나 호환성이 부족하다는 것입니다.
  • Duktape: Duktape는 C 언어로 작성된 임베디드 자바스크립트 엔진입니다. Duktape는 ES5 표준을 지원하며, ES6의 일부 기능도 사용할 수 있습니다. Duktape의 장점은 메모리 사용량이 적고 소스 코드가 작다는 것이고, 단점은 성능이나 호환성이 낮다는 것입니다.
  • GraalVM: GraalVM은 자바스크립트를 비롯한 여러 언어를 실행할 수 있는 고성능 런타임 환경입니다. GraalVM은 JIT 컴파일러와 폴리글랏 엔진을 통해 다양한 언어 간의 상호 운용성과 최적화를 제공합니다. GraalVM의 장점은 속도가 빠르고 유연하다는 것이고, 단점은 설치나 설정이 복잡하다는 것입니다.
  • Rhino: Rhino는 자바로 작성된 자바스크립트 엔진입니다. Rhino는 자바와 자바스크립트 간의 통합을 쉽게 할 수 있게 해줍니다. Rhino의 장점은 자바와 호환되고 안정적이라는 것이고, 단점은 성능이나 메모리 사용량이 높다는 것입니다.

References

(1) "데노 vs. Node.js" JS 런타임 선택 가이드 - ITWorld Korea (2) [JavaScript] 자바스크립트 런타임 | Beomy (3) JavaScript 기반 라이브러리, 프레임워크 비교 (4) [JavaScript] 자바스크립트 런타임 | Beomy (5) 런타임 환경 (6) Windows에서 Java 런타임 설정 업데이트

Vite와 Deno

Vite는 자바스크립트 빌드 도구이고, Deno는 자바스크립트 런타임 환경입니다. Vite는 웹팩과 같은 번들러를 대체하는 빌드 도구입니다. Vite는 ES 모듈을 기반으로 하여 개발 서버와 프로덕션 빌드를 제공합니다. Vite의 장점은 속도가 빠르고 설정이 쉽다는 것이고, 단점은 호환성이나 안정성이 낮다는 것입니다. Deno는 Node.js와 유사한 자바스크립트와 타입스크립트를 위한 런타임 환경입니다. Deno는 보안과 표준을 중시하며, URL을 통해 모듈을 가져올 수 있습니다. Deno의 장점은 보안이 강하고 타입스크립트를 지원한다는 것이고, 단점은 생태계가 작고 호환성이 낮다는 것입니다.

References

(1) 차세대 빌드 도구 비교 | TOAST UI :: Make Your Web Delicious! (2) vite and deno: an experiment - DEV Community (3) [Deno] Node.js의 대안!! Deno 알아보기 - Dev. DY

자바스크립트 빌드 도구

자바스크립트 빌드 도구에는 웹팩, 롤업, 스노우팩, Vite 등이 있습니다. 웹팩은 가장 널리 사용되는 빌드 도구로, 모듈 번들러라고도 합니다. 웹팩은 자바스크립트뿐만 아니라 HTML, CSS, 이미지 등의 리소스도 모듈로 취급하여 의존성을 분석하고 하나의 파일로 번들링합니다. 웹팩의 장점은 다양한 플러그인과 로더를 통해 많은 기능을 제공한다는 것이고, 단점은 설정이 복잡하고 느리다는 것입니다. 롤업은 웹팩과 유사한 모듈 번들러입니다. 롤업은 ES 모듈을 기준으로 하여 트리 쉐이킹과 코드 스플리팅을 지원합니다. 롤업의 장점은 ES 모듈을 최적화하여 작고 효율적인 번들을 생성한다는 것이고, 단점은 웹팩보다 지원하는 기능이 적다는 것입니다. 스노우팩과 Vite는 ES 모듈을 기반으로 한 차세대 빌드 도구입니다. 스노우팩과 Vite는 개발 서버와 프로덕션 빌드를 제공합니다. 스노우팩과 Vite의 장점은 속도가 빠르고 설정이 쉽다는 것이고, 단점은 호환성이나 안정성이 낮다는 것입니다.

References

(1) 자바스크립트 개발 도구와 테스트-3 :: JS 탐구생활 (2) [learning javascript] chapter 2. 자바스크립트 개발 도구 (3) 차세대 빌드 도구 비교 | TOAST UI :: Make Your Web Delicious!

웹팩 빌드 도구를 베이스로 하는 프레임워크는 Nuxt.js와 Next.js 등이 있습니다. 이들은 웹팩을 사용하여 서버 측 렌더링을 지원하는 메타 프레임워크입니다. 바벨은 웹팩과 별개의 도구로, 자바스크립트 코드를 변환해주는 컴파일러입니다. 바벨은 최신 자바스크립트 문법을 구형 브라우저에서도 동작할 수 있도록 호환성을 보장해줍니다. 웹팩은 바벨을 로더로 사용하여 모듈 번들링 과정에서 코드 변환을 수행할 수 있습니다.

References

(1) 차세대 빌드 도구 비교 | TOAST UI :: Make Your Web Delicious! (2) 웹팩과 바벨 무엇이 다른가. 리액트에서는 뭘 써야 할까? · Tonic (3) Webpack과 Babel을 이용한 React 개발 환경 구성하기 | Berkbach (4) [나만의 웹팩 만들기] 2. babel 추가하기 | hoilzz (5) Webpack이란 무엇인가? 정의와 필요성, 그리고 장단점 | 하늘네트 (6) 2022년 웹 개발을 위한 상위 10가지 최고의 웹 백엔드 프레임워크 ...

Parcel 번들러

Parcel도 웹팩과 비슷한 번들러입니다. Parcel은 웹팩보다 설정이 간단하고 빠른 번들링 속도를 자랑합니다. 하지만 웹팩보다는 기능이 적고 커스터마이징이 어렵습니다. 웹팩 대체 번들러로는 Vite, Rollup, Snowpack 등이 있습니다. 이들은 모두 웹팩보다 더 빠르고 간편하게 번들링을 할 수 있다고 주장합니다. 하지만 각각 장단점이 있으므로 프로젝트의 목적과 요구사항에 따라 적절한 번들러를 선택하는 것이 중요합니다.

References

(1) Parcel 한국어판 (2) 🚀 시작하기 (3) 리액트 프로젝트 초기 설정 - CRA vs Vite (4) Parcel로 빠르게 프로젝트 시작하기 (5) Webpack : 웹팩 찍먹하기 (+ module, bundler, loader) (6) (Webpack) 웹팩 - 모듈 번들러와 로더 | Let's Sunny

웹팩이 모듈화할 수 있는 리소스

웹팩은 모듈 번들러로서, 자바스크립트 파일뿐만 아니라 CSS, HTML, 이미지, 폰트 등의 리소스 파일도 모듈로 취급합니다. 이렇게 하면 각 리소스 파일을 재사용하고 의존성 관리를 할 수 있습니다.

  • ECMAScript 모듈
  • CommonJS 모듈
  • AMD 모듈
  • Assets (CSS, HTML, 이미지, 폰트 등)
  • WebAssembly 모듈

그 밖에도 웹팩은 로더를 통해 다양한 언어와 전처리기로 작성된 모듈을 지원합니다. 예를 들어 TypeScript, Sass, Babel 등의 로더가 있습니다.

References

(1) JavaScript | Webpack 기초 정리 :: Pathas' Path as Web Developer (2) [스터디 with 실전 리액트 프로그래밍] 17편 - 웹팩 (3) Module | 웹팩 (4) Modules | 웹팩 (5) Webpack : 웹팩 찍먹하기 (+ module, bundler, loader)

웹팩의 로더와 플러그인은 다음과 같이 차이점이 있습니다.

  • 로더는 파일을 해석하고 변환하는 과정에 관여합니다. 예를 들어 CSS 파일을 자바스크립트로 변환하거나 TypeScript를 자바스크립트로 컴파일하는 등의 작업을 수행합니다.
  • 플러그인은 웹팩의 기본적인 동작에 추가적인 기능을 제공합니다. 예를 들어 번들된 결과물을 난독화하거나 특정 텍스트를 추출하는 등의 작업을 수행합니다. 로더는 모듈 규칙(module.rules) 속성에 배열 형태로 설정하고, 플러그인은 플러그인(plugins) 속성에 배열 형태로 설정합니다.

References

(2) [javascript] Webpack 로더 대 플러그인; 차이점이 뭐야? - 리뷰나라 (3) 플러그인 - 웹팩(Webpack) 기본편 | 김정환 :: Interactive Developer (4) Plugin | 웹팩 핸드북 (5) javascript — 웹팩 로더와 플러그인; 차이점이 뭐야? (6) [TIL]Webpack과 인사하기 - 웹팩 기본 사용법, 모드/로더/아웃풋

웹팩의 모드와 환경변수는 다음과 같이 설명할 수 있습니다.

  • 웹팩의 모드는 웹팩의 동작 방식을 결정하는 옵션입니다. development, production, none 중 하나를 선택할 수 있습니다. 각 모드에 따라 웹팩은 내부적으로 최적화를 수행하거나 소스맵을 생성하거나 프로세스 환경 변수를 설정합니다.
  • 웹팩의 환경변수는 웹팩이 실행되는 노드 환경에서 사용할 수 있는 변수입니다. 예를 들어 dotenv 모듈을 사용하여 .env 파일에 저장된 변수들을 불러올 수 있습니다. 또한 webpack.DefinePlugin을 사용하여 전역 변수로 등록하여 코드 내에서 구분할 수 있게 할 수 있습니다.

References

(1) Concepts | 웹팩 (2) [Webpack] Webpack과 환경변수 (3) Webpack Dev Server를 이용한 개발 환경 구성 Part1 (4) dotenv를 사용한 NodeJS 환경변수 설정과 Webpack 번들로 환경변수 ...

웹팩의 엔트리와 아웃풋

  • 엔트리는 웹팩이 모듈을 해석하고 번들링하는 시작점입니다. 엔트리에 지정된 파일부터 의존하는 모듈들을 찾아내어 하나의 결과물로 만듭니다. 엔트리는 entry 속성에 문자열이나 배열이나 객체로 설정할 수 있습니다.
  • 아웃풋은 웹팩이 번들링한 결과물을 저장할 위치와 파일명을 지정하는 옵션입니다. 아웃풋은 output 속성에 객체로 설정하며, path와 filename 속성은 필수입니다. path는 절대경로를 사용해야 하고, filename은 [name], [hash], [chunkhash] 등의 키워드를 사용할 수 있습니다.

References

(1) 프론트엔드 개발환경의 이해: 웹팩(기본) | 김정환 블로그 (2) 프론트엔드 개발환경: 웹팩

일반적으로 많이 사용되는 웹팩 플러그인과 로더

  • 플러그인

- HtmlWebpackPlugin: HTML 파일을 생성하고 번들링된 스크립트를 자동으로 삽입해주는 플러그인입니다.   - MiniCssExtractPlugin: CSS 파일을 별도로 추출하고 HTML 파일에 링크하는 플러그인입니다.   - CleanWebpackPlugin: 빌드 전에 output 폴더를 자동으로 삭제해주는 플러그인입니다.   - OptimizeCssAssetsWebpackPlugin: CSS 파일을 최적화하고 압축하는 플러그인입니다.   - TerserWebpackPlugin: JS 파일을 최적화하고 압축하는 플러그인입니다.

  • 로더

- babel-loader: 바벨을 사용하여 JS 파일을 변환하는 로더입니다.   - css-loader: CSS 파일을 모듈로 인식할 수 있게 해주는 로더입니다.   - style-loader: CSS 파일을 동적으로 스타일 태그로 삽입해주는 로더입니다.   - file-loader: 이미지나 폰트 등의 파일을 모듈로 인식할 수 있게 해주는 로더입니다.   - url-loader: 작은 크기의 이미지나 폰트 등의 파일을 base64로 인코딩하여 JS나 CSS에 내장시켜주는 로더입니다.

References

(1) 웹팩 설정하기 - 플러그인 (2) Webpack : 웹팩 찍먹하기 (+ module, bundler, loader) (3) 최고의 10가지 워드프레스 플러그인 추천 (2020) | 옵티머 (4) (Webpack) 웹팩 - 모듈 번들러와 로더 | Let's Sunny (5) 사용중인 VSCode(Visual Studio Code) 확장 플러그인 목록 (6) Loaders | 웹팩

웹팩의 설정 방법

  • 웹팩을 설치하기 위해서는 npm을 이용해야 합니다. npm은 Node.js를 설치하면 함께 설치됩니다.
  • 웹팩과 웹팩 CLI 패키지를 설치합니다. CLI는 커맨드 라인 인터페이스로, 터미널에서 웹팩 명령어를 사용할 수 있게 해줍니다.
  • 웹팩에서 기본적으로 인식하는 설정 파일 이름은 webpack.config.js입니다. 이 파일을 프로젝트 루트 폴더에 생성합니다.
  • 설정 파일에는 mode, entry, output, module, plugins 등의 속성을 정의할 수 있습니다.   - mode: 개발 모드(development)와 배포 모드(production)를 구분하여 최적화 옵션을 적용할 수 있습니다.   - entry: 번들링할 파일의 시작점을 지정합니다.   - output: 번들링된 결과물의 파일명과 경로를 지정합니다.   - module: 로더를 사용하여 다양한 형식의 파일들을 모듈로 변환할 수 있습니다. rules 배열에 각각의 로더와 적용할 파일 확장자를 정의합니다.   - plugins: 번들링 과정에 추가적인 기능을 제공하는 플러그인들을 사용할 수 있습니다. plugins 배열에 각각의 플러그인 객체를 생성하여 넣습니다.

References

(1) [webpack] webpack 설치부터 실행까지 (2) 웹팩(Webpack) 기본 설정법 (Entry/Output/Loader/Plugins) (3) 웹팩(Webpack) 기본 사용법 (CLI) | Engineering Blog by Dale Seo

· 약 23분
Dongmin Yu

Node.js 패키지 매니저

Node.js 패키지 매니저는 Node.js에서 사용할 수 있는 모듈을 패키지 형태로 저장해 둔 패키지 생태계이자 패키지 설치 및 관리를 위한 CLI를 제공하는 도구입니다. npm은 Node.js와 함께 설치되어 가장 널리 쓰이는 패키지 매니저입니다. Yarn과 pnpm 외에도 다른 패키지 매니저들이 있습니다. 예를 들어, cnpm, ied, npmd 등이 있습니다. 각 도구마다 장단점이 있으므로 프로젝트의 요구사항과 개인의 취향에 따라 선택하시면 됩니다.

References

(1) [Node.js] 인기 NPM 패키지 알아보기 | 가비아 라이브러리 (2) 처음 시작하는 Node.js 개발 - 2 - npm | HEROPY (3) 패키지 매니저로 Node.js 설치하기 | Node.js (4) Installing Node.js via package manager | Node.js (5) npm - a JavaScript package manager

각 패키지 매니저의 강점

  • npm: Node.js와 함께 설치되어 가장 널리 쓰이는 패키지 매니저입니다. 모든 Node.js 모듈을 호환하고 사용하기 쉽습니다.
  • yarn: npm보다 빠르고 안정적인 설치 속도를 제공합니다. 오프라인 모드와 워크스페이스 기능을 지원합니다.
  • pnpm: 디스크 공간과 메모리를 절약하는 방식으로 패키지를 설치합니다. 중복된 패키지를 하나의 복사본으로 관리하고 심볼릭 링크로 연결합니다.
  • cnpm: 중국에서 개발된 패키지 매니저로 npm의 미러 서버를 사용하여 중국 내에서 빠른 다운로드 속도를 제공합니다.

References

(1) JavaScript package managers compared: npm, Yarn, or pnpm? (2) JavaScript Package Managers: NPM Vs YARN Vs PNPM - Atatus (3) Why you should prefer using pnpm over npm and yarn? | refine

리액트 네이티브 개발의 패키지 매니저

yarn berry와 pnpm은 모두 Plug'n'Play(PnP)라는 기능을 지원합니다. PnP는 패키지를 설치할 때 node_modules 폴더를 생성하지 않고, 하나의 복사본으로 관리하고 심볼릭 링크로 연결하는 방식입니다. 이렇게 하면 디스크 공간과 메모리를 절약하고 설치 속도를 향상시킬 수 있습니다. 그러나 yarn berry와 pnpm은 PnP를 구현하는 방식에 차이가 있습니다. yarn berry는 PnP를 기본적으로 활성화하고, 호환되지 않는 패키지들을 위해 loose 모드라는 옵션을 제공합니다. pnpm은 PnP 대신 node_modules 폴더에 심볼릭 링크를 생성하는 방식을 사용합니다. 이 방식은 호환성 문제가 적으나, 일부 패키지들이 심볼릭 링크로 인식하지 못하는 경우가 있습니다. 따라서 리액트 네이티브 개발자에게 어떤 패키지 매니저가 더 적합한지는 프로젝트의 특성과 사용하는 패키지들에 따라 다르겠습니다. 일반적으로 yarn berry는 PnP의 장점을 최대한 활용하고 싶은 경우에 좋으며, pnpm은 node_modules 폴더의 구조를 유지하면서 캐싱의 장점을 얻고 싶은 경우에 좋습니다.

References

(1) Advanced package manager features for npm, Yarn, and pnpm (2) JavaScript package managers compared: npm, Yarn, or pnpm? (3) Plug'n'Play | Yarn - Package Manager (4) reactjs - NPM or Yarn? What is the standard practice of starting React Native projects ...

두 패키지 도구의 차이점과 각각의 장단점

yarn berry와 pnpm의 차이점

  • yarn berry는 PnP를 기본적으로 활성화하고, 호환되지 않는 패키지들을 위해 loose 모드라는 옵션을 제공합니다. pnpm은 PnP 대신 node_modules 폴더에 심볼릭 링크를 생성하는 방식을 사용합니다.
  • yarn berry는 워크스페이스 기능을 지원하며, 여러 프로젝트를 하나의 저장소에서 관리할 수 있습니다. pnpm은 워크스페이스 기능을 지원하지 않으며, 각 프로젝트마다 별도의 패키지 매니저를 사용해야 합니다.
  • yarn berry는 플러그인 시스템을 제공하며, 다양한 기능들을 추가할 수 있습니다. pnpm은 플러그인 시스템을 제공하지 않으며, 필요한 기능들은 별도의 도구나 스크립트로 구현해야 합니다.

yarn berry와 pnpm의 장단점

  • yarn berry의 장점은 PnP의 장점을 최대한 활용하고 싶은 경우에 좋으며, 워크스페이스와 플러그인 등 다양한 기능들을 제공한다는 점입니다. 단점은 PnP가 호환되지 않는 패키지들이 있어서 loose 모드를 사용해야 하는 경우가 있다는 점입니다.
  • pnpm의 장점은 node_modules 폴더의 구조를 유지하면서 캐싱의 장점을 얻고 싶은 경우에 좋으며, 호환성 문제가 적다는 점입니다. 단점은 워크스페이스와 플러그인 등 다양한 기능들이 부족하다는 점입니다.

References

(1) JavaScript Package Managers: NPM Vs YARN Vs PNPM - Atatus (2) JavaScript package managers compared: npm, Yarn, or pnpm? (3) Benchmarks of JavaScript Package Managers | pnpm

yarn berry와 pnpm 각각에 대한 성능 벤치마크 결과

  • yarn berry는 PnP 모드를 사용하면 설치 시간이 가장 빠르고, 캐시가 없는 경우에도 빠른 속도를 유지합니다. 하지만 업데이트 시간은 다른 패키지 매니저들보다 느립니다.
  • pnpm은 캐시가 있는 경우에 설치 시간이 가장 빠르고, 캐시가 없는 경우에도 yarn berry보다 느리지 않습니다. 업데이트 시간은 npm보다 빠르고, yarn classic보다 조금 느립니다. 성능 벤치마크 결과는 프로젝트의 크기나 구조에 따라 달라질 수 있으므로 참고만 하시기 바랍니다.

References

(1) Benchmarks of JavaScript Package Managers | pnpm (2) JavaScript package managers compared: npm, Yarn, or pnpm? (3) pnpm/benchmarks-of-javascript-package-managers - GitHub

yarn berry가 업데이트 시간이 느린 이유

  • yarn berry는 PnP 모드를 사용하면 node_modules 폴더를 생성하지 않고, .pnp.js 파일에 패키지의 위치를 기록합니다. 이 방식은 설치 시간을 줄여주지만, 업데이트 시간을 늘리는 단점이 있습니다.
  • yarn berry는 업데이트할 때 peer dependencies의 충돌 여부를 체크하고, 문제가 있으면 경고 메시지를 출력합니다. 이 과정은 업데이트 시간에 영향을 줄 수 있습니다.

yarn berry의 업데이트 시간을 최소화하는 방법

  • yarn berry의 설정 파일인 .yarnrc.yml 파일에 nodeLinker: node-modules 라고 추가하면 PnP 모드를 비활성화하고, node_modules 폴더를 생성하는 방식으로 바꿀 수 있습니다. 이렇게 하면 업데이트 시간이 줄어들 수 있습니다.
  • yarn berry의 명령어인 yarn up 을 사용하면 패키지들을 최신 버전으로 업데이트할 수 있습니다. 이 명령어는 peer dependencies의 충돌 여부를 무시하므로, 경고 메시지가 나오지 않습니다. 하지만 peer dependencies가 정상적으로 작동하지 않을 수도 있으므로 주의해야 합니다.

References

(1) Migration | Yarn - Package Manager (2) Make your CI faster and improve developer experience: Upgrade to Yarn >2 with (or ... (3) [Bug?]: yarn install link step very slow · Issue #3476 · yarnpkg/berry - GitHub

yarn berry의 loose 모드 활성화 방법

  • yarn berry의 설정 파일인 .yarnrc.yml 파일에 pnpMode: loose 라고 추가하면 loose 모드를 활성화할 수 있습니다.
  • loose 모드는 PnP 모드와 비슷하지만, node_modules 링커에서 hoist되었을 패키지들에 대해서는 경고 메시지만 출력하고 접근을 허용합니다. 이렇게 하면 호환성 문제를 줄일 수 있습니다.

특정 패키지가 PnP를 지원하지 않는 것을 미리 알 수 있는 방법

  • yarn berry의 명령어인 yarn dlx @yarnpkg/doctor 을 사용하면 프로젝트에 있는 패키지들이 PnP를 지원하는지 검사할 수 있습니다. 이 명령어는 문제가 있는 패키지들을 보여주고, 해결 방법을 제안합니다.
  • yarn berry 웹사이트 에서 패키지 이름을 검색하면 해당 패키지가 PnP를 지원하는지 여부를 확인할 수 있습니다. PnP를 지원하는 패키지는 아이콘으로 표시됩니다.

References

(1) berry/CHANGELOG.md at master · yarnpkg/berry · GitHub (2) yarnpkg - Fallback pool in yarn v2 "loose" mode - Stack Overflow (3) Yarn 2.1 🐱‍🏍 Git Workspaces, Focused Installs, Loose mode, Live Playground ...

yarn berry에서 nodeLinker: node_modules 옵션과 pnpMode: loose 옵션의 차이점

  • nodeLinker: node_modules 옵션은 PnP 모드를 완전히 비활성화하고, 전통적인 node_modules 폴더를 생성하는 방식으로 패키지들을 설치하고 관리합니다. 이 옵션은 호환성 문제를 없애지만, 설치 시간과 디스크 공간을 많이 소모합니다.
  • pnpMode: loose 옵션은 PnP 모드를 부분적으로 활성화하고, node_modules 링커에서 hoist되었을 패키지들에 대해서는 경고 메시지만 출력하고 접근을 허용합니다. 이 옵션은 호환성 문제를 줄이면서도 설치 시간과 디스크 공간을 절약할 수 있습니다.

두 옵션은 동시에 사용할 수 없습니다. 왜냐하면 두 옵션은 서로 다른 링커 방식을 사용하기 때문입니다. 만약 두 옵션을 동시에 설정하면 yarn berry는 오류 메시지를 출력하고 작동하지 않습니다.

References

(1) Advanced package manager features for npm, Yarn, and pnpm (2) yarnpkg - Yarn 3 nodeLinker: node-modules - Stack Overflow (3) Yarn PnP 의존성 에러 해결기 | 햣 블로그 (4) Plug'n'Play | Yarn - Package Manager (5) Default nodeLinker is node_modules instead of pnp · Issue #3482 · yarnpkg/berry ...

yarn berry 마이그레이션 방법

yarn classic을 사용하던 프로젝트에서 yarn berry로 업데이트하고 나서, 다음과 같은 작업을 해야 합니다:

  • yarn set version berry 명령어를 실행하여 yarn berry를 활성화합니다.
  • .npmrc나 .yarnrc 파일이 있다면 새로운 형식인 .yarnrc.yml 파일로 변환합니다. 이 과정에서 기존의 설정들을 유지하거나 변경할 수 있습니다.
  • yarn install 명령어를 실행하여 프로젝트의 의존성들을 설치합니다. 이때 PnP 모드가 기본적으로 적용되므로 호환성 문제가 발생할 수 있습니다. 이런 경우에는 nodeLinker: node_modules 옵션을 사용하거나 pnpMode: loose 옵션을 사용하여 해결할 수 있습니다.
  • package.json 파일에 있는 scripts 설정들을 검토하고 필요한 경우 수정합니다. 예를 들어 node_modules 폴더에 직접 접근하는 스크립트는 PnP 모드와 충돌할 수 있으므로 yarn dlx 명령어를 사용하여 대체할 수 있습니다.

.yarnrc.yml 파일과 .yarnrc 파일은 동시에 사용할 수 없습니다. 왜냐하면 두 파일은 서로 다른 형식의 설정 파일이기 때문입니다. 만약 두 파일이 동시에 존재한다면 yarn berry는 오류 메시지를 출력하고 작동하지 않습니다.

References

(1) Migration | Yarn - Package Manager (2) Feedback on Yarn 3 migration from Yarn classic · Discussion #3448 · yarnpkg/berry ... (3) yarnpkg/yarn: The 1.x line is frozen - GitHub

yarn berry의 dlx 커맨드

  • dlx 커맨드는 npx 커맨드와 유사하게 한 번만 실행할 패키지를 설치하고 실행하는 명령어입니다. 예를 들어 yarn dlx create-react-app 명령어는 create-react-app 패키지를 임시로 설치하고 프로젝트를 생성한 후 삭제합니다.
  • dlx 커맨드는 yarn berry의 PnP 모드와 호환되도록 설계되었습니다. 따라서 node_modules 폴더에 직접 접근하는 패키지들을 dlx 커맨드로 대체할 수 있습니다. 예를 들어 yarn dlx eslint --init 명령어는 eslint 패키지를 임시로 설치하고 설정 파일을 생성한 후 삭제합니다.
  • dlx 커맨드는 -p,--package 플래그를 사용하여 실행할 패키지와 실행할 명령어를 구분할 수 있습니다. 예를 들어 yarn dlx -p jest jest 명령어는 jest 패키지에서 jest 명령어를 실행합니다.

References

(1) yarn dlx | Yarn - Package Manager (2) GitHub - yarnpkg/berry: 📦🐈 Active development trunk for Yarn ⚒ (3) Yarn berry에서 React + Jest + Cypress + TypeScript + Github Actions CI/CD를 ... (4) yarn berry로 React.js 프로젝트 시작하기 | Kasterra's Archive (5) Migration | Yarn - Package Manager

yarn dlx 명령어와 npx 명령어의 충돌 가능성

dlx 커맨드는 npx 커맨드와 거의 동일한 기능을 제공하지만 yarn berry의 PnP 모드와 호환되도록 만들어졌습니다. 따라서 yarn berry를 사용하는 프로젝트에서는 dlx 커맨드를 사용하는 것이 권장됩니다. npx 커맨드는 node_modules 폴더에 의존하기 때문에 PnP 모드와 충돌할 수 있습니다.

패키지 매니저는 프로젝트의 의존성을 관리하는 도구입니다. 각 프로젝트마다 다른 패키지 매니저를 사용할 수 있습니다. 예를 들어, npm, yarn, pnpm 등의 패키지 매니저를 선택할 수 있습니다.

각 패키지 매니저는 자신만의 장단점이 있으므로, 프로젝트의 목적과 요구사항에 따라 적합한 패키지 매니저를 선택하는 것이 좋습니다. 또한, 패키지 매니저를 바꾸고 싶다면, 기존에 설치된 패키지들을 삭제하고 새로운 패키지 매니저로 다시 설치하는 과정이 필요합니다. 각 패키지 매니저 사이에 간섭은 전혀 없다고 단언하기는 어렵습니다. 가능하면 한 프로젝트에서는 한 가지 패키지 매니저만 사용하시는 것이 안전하고 편리할 것입니다.

References

(1) Package management basics - Learn web development | MDN - Mozilla (2) JavaScript package managers compared: npm, Yarn, or pnpm? (3) Adding Nuget Packages From One Project To Another

Yarn Berry로 업그레이드하지 않아도 되는 경우

pnpm과 yarn berry를 프로젝트에 적용시켜 보고자 하는 개발자들을 대상으로, 다음과 같은 경우에는 기존의 npm이나 yarn classic을 쓰는 게 낫다고 말할 수 있습니다:

  • Node.js의 버전이 16.9.0 미만인 경우: pnpm과 yarn berry는 Corepack이라는 도구를 사용하여 패키지 매니저를 관리합니다. 하지만 Corepack은 Node.js 16.9.0 이상에서만 사전 설치되어 있으므로, 그 이하의 버전에서는 별도로 설치하고 활성화해야 합니다. 이 과정이 번거롭거나 오류가 발생할 수 있는 경우에는 npm이나 yarn classic을 사용하는 것이 편리할 수 있습니다.
  • 패키지가 node_modules 폴더에 의존하는 경우: pnpm과 yarn berry는 node_modules 폴더를 생성하지 않고, 의존성을 공유하거나 가상화하는 방식으로 패키지를 관리합니다. 이는 디스크 공간과 설치 속도를 절약할 수 있지만, node_modules 폴더에 직접 접근하거나 수정하는 패키지와 호환되지 않을 수 있습니다. 이런 패키지들은 pnpm의 --shamefully-hoist 옵션이나 yarn berry의 nodeLinker 옵션으로 해결할 수 있기도 하지만, 그렇게 되면 pnpm과 yarn berry의 장점을 잃게 될 수 있습니다. 따라서 이런 패키지들을 사용해야 하는 경우에는 npm이나 yarn classic을 사용하는 것이 안전할 수 있습니다.

위의 예시 외에도 다른 상황에 따라서 pnpm과 yarn berry가 적합하지 않을 수도 있습니다. 따라서 프로젝트의 특성과 요구사항을 잘 파악하고, 패키지 매니저를 선택하시기 바랍니다.

References

(1) JavaScript package managers compared: npm, Yarn, or pnpm? (2) Why you should prefer using pnpm over npm and yarn? | refine (3) JavaScript Package Managers: NPM Vs YARN Vs PNPM - Atatus

yarn classic, yarn berry, pnpm의 인기

yarn classic과 pnpm, yarn berry의 각 사용자 비율을 정확하게 알려주기는 어렵습니다. 패키지 매니저의 사용률은 다양한 요인에 따라 변화할 수 있고, 중복 사용자가 많을 수 있기 때문입니다. 하지만 대략적인 사용률을 알고 싶으시다면, 다음과 같은 방법으로 참고할 수 있습니다:

  • npm registry에서 각 패키지 매니저의 다운로드 횟수를 확인하는 방법: 이 방법은 각 패키지 매니저의 인기도를 나타낼 수 있습니다. 예를 들어, 2022년 12월 1일부터 2023년 1월 8일까지의 기간 동안, yarn classic은 약 2억 5천만번 다운로드되었고, pnpm은 약 1천만번 다운로드되었으며, yarn berry는 약 3백만번 다운로드되었습니다. 이 결과를 보면, yarn classic이 가장 인기있는 패키지 매니저라고 할 수 있습니다.
  • 각 패키지 매니저의 벤치마크 결과를 확인하는 방법: 이 방법은 각 패키지 매니저의 성능을 비교할 수 있습니다. 예를 들어, pnpm 공식 웹사이트에서 제공하는 벤치마크 결과에 따르면, pnpm이 npm과 yarn classic보다 설치 속도와 디스크 공간 절약 면에서 우수하다고 합니다. 또한 yarn berry는 node_modules 폴더를 생성하지 않는 PnP 모드로 실행될 때 가장 빠른 설치 속도와 가장 적은 디스크 공간을 차지한다고 합니다. 이 결과를 보면, pnpm과 yarn berry가 성능 면에서 우위에 있다고 할 수 있습니다.

References

(1) JavaScript package managers compared: npm, Yarn, or pnpm? (2) JavaScript Package Managers: NPM Vs YARN Vs PNPM - Atatus (3) Benchmarks of JavaScript Package Managers | pnpm

· 약 26분
Dongmin Yu

What is Yarn Berry?

Yarn Berry는 Yarn의 새로운 버전으로, Node.js를 위한 패키지 관리 시스템입니다. Yarn Berry는 node_modules 폴더를 사용하지 않고 zip 파일로 모듈들을 관리하며, Plug'n'Play (PnP)라는 기능을 제공합니다. PnP는 모듈 설치 시간을 줄이고 디스크 공간을 절약하며 호환성 문제를 해결하는 등의 장점이 있습니다. Yarn Berry를 사용하려면 다음과 같은 단계를 따라야 합니다:

  • npm install -g yarn 명령어로 글로벌 yarn 버전을 최신 v1으로 업데이트합니다.
  • 프로젝트 디렉토리로 이동합니다.
  • yarn set version berry 명령어로 v2를 활성화합니다.
  • .npmrc 또는 .yarnrc 파일이 있다면 새로운 형식으로 변경합니다.
  • .yarnrc.yml 파일에 nodeLinker: node-modules 를 추가합니다.

References

(1) node_modules로부터 우리를 구원해 줄 Yarn Berry (2) [Devlog] yarn berry (3) yarn berry로 React.js 프로젝트 시작하기 | Kasterra's Archive (4) GitHub - yarnpkg/berry: 📦🐈 Active development trunk for Yarn ⚒ (5) Migration | Yarn - Package Manager

yarn Berry와 Yarn Classic의 차이점

Yarn Berry와 Yarn Classic의 가장 큰 차이점은 모듈 관리 방식입니다. Yarn Classic은 node_modules 폴더에 모든 의존성을 설치하고, package.json 파일에 버전 정보를 기록합니다. Yarn Berry는 zip 파일로 모든 의존성을 압축하고, .yarn 폴더에 저장합니다. 또한 package.json 파일 대신 .yarnrc.yml 파일에 버전 정보를 기록합니다. 이러한 차이점으로 인해 Yarn Berry는 설치 속도가 빠르고 디스크 공간을 절약하며 호환성 문제를 해결할 수 있습니다. 그러나 Yarn Berry는 아직 새로운 버전이기 때문에 일부 툴이나 라이브러리와의 호환성 문제가 발생할 수 있습니다. 따라서 프로젝트의 특성과 요구사항에 따라 적절한 버전을 선택하는 것이 중요합니다.

References

(1) Migration | Yarn - Package Manager (2) GitHub - yarnpkg/berry: 📦🐈 Active development trunk for Yarn ⚒ (3) yarnpkg - Difference between yarn versions - Stack Overflow

Yarn Berry의 장점

  • 설치 시간이 빠릅니다. zip 파일로 모듈을 관리하고 캐시를 사용하기 때문에 node_modules 폴더를 생성하거나 의존성을 다운로드할 필요가 없습니다.
  • 디스크 공간을 절약합니다. zip 파일은 일반 파일보다 용량이 작으며, 캐시를 공유할 수 있기 때문에 중복된 모듈을 저장할 필요가 없습니다.
  • 호환성 문제를 해결합니다. PnP 기능을 사용하면 모듈 간의 충돌이나 버전 문제를 방지할 수 있습니다.

Yarn Berry의 단점

  • 저장소 크기가 증가합니다. zip 파일을 저장소에 푸시하면 git이 모든 변경 내역을 기억하기 때문에 저장소의 크기가 커질 수 있습니다.
  • 클론 시간이 증가합니다. 저장소 크기가 커지면 클론하는데 걸리는 시간도 길어질 수 있습니다.
  • 일부 툴이나 라이브러리와 호환되지 않을 수 있습니다. Yarn Berry는 아직 새로운 버전이기 때문에 일부 툴이나 라이브러리가 node_modules 폴더나 package.json 파일에 의존하는 경우 호환성 문제가 발생할 수 있습니다.

따라서 Yarn Berry를 사용하기 전에 프로젝트의 특성과 요구사항에 따라 장단점을 고려하는 것이 좋습니다.😊

References

(1) Should i push the .yarn/cache folder to Github - Yarn2 (2) State of Yarn 2 (Berry) in 2021 · Hao's learning log (3) Yarn 1 vs Yarn 2 vs NPM - Medium

Yarn Berry don't need package.json?

Yarn Berry는 package.json 파일을 사용하지 않는 것이 아니라, package.json 파일에 버전 정보를 기록하지 않는 것입니다. Yarn Berry는 대신 .yarnrc.yml 파일에 버전 정보를 기록합니다. 따라서 package.json 파일은 여전히 프로젝트의 이름, 설명, 스크립트 등의 정보를 담고 있습니다.😊

Yarn Berry를 사용하는 Node.js 프로젝트의 gitignore 파일을 작성하는 방법

  • .yarn 폴더 내에 있는 캐시 파일들은 저장소에 커밋하지 않는 것이 좋습니다. 이 파일들은 zip 파일로 압축된 모듈들이며, 저장소의 용량을 증가시킬 수 있습니다. 따라서 .yarn/cache 폴더를 gitignore 파일에 추가합니다.
  • .yarn 폴더 내에 있는 설정 파일들은 저장소에 커밋하는 것이 좋습니다. 이 파일들은 Yarn Berry의 버전 정보나 PnP 설정 등을 담고 있으며, 프로젝트의 의존성 관리에 필요합니다. 따라서 .yarnrc.yml 파일이나 .pnp.js 파일 등을 gitignore 파일에서 제외합니다.
  • node_modules 폴더는 Yarn Berry를 사용하면 생성되지 않으므로 gitignore 파일에 추가할 필요가 없습니다.

따라서 Yarn Berry를 사용하는 Node.js 프로젝트의 gitignore 파일은 다음과 같이 작성할 수 있습니다:

# Ignore cache files
.yarn/cache

# Do not ignore settings files
!.yarnrc.yml
!.pnp.js

References

(1) berry/.gitignore at master · yarnpkg/berry · GitHub (2) [Question] What files should be listed in .gitignore ? · Issue #454 · yarnpkg/berry (3) Better gitignore for Yarn 2 (berry) see [https://github.com/github/gitignore/pull/3479]

Yarn Classic에서 Yarn Berry로 마이그레이션할 때 수정해야 할 사항

  • Yarn Berry를 활성화합니다. yarn set version berry 명령어를 실행하면 프로젝트에 .yarn 폴더와 .yarnrc.yml 파일이 생성됩니다. 이 파일들은 Yarn Berry의 버전 정보와 설정을 담고 있습니다.
  • 설정 파일을 새로운 형식으로 변환합니다. 만약 .npmrc나 .yarnrc 파일을 사용했다면, 이 파일들을 .yarnrc.yml 파일에 병합해야 합니다. 예를 들어, registry "https://registry.yarnpkg.com" 라는 설정은 npmRegistryServer: "https://registry.yarnpkg.com" 로 바꿔야 합니다.
  • 의존성을 설치합니다. yarn install 명령어를 실행하면 의존성들이 zip 파일로 압축되어 .yarn/cache 폴더에 저장됩니다. 또한 PnP 모드가 기본적으로 활성화되므로 node_modules 폴더가 생성되지 않습니다.
  • 호환성 문제를 해결합니다. 일부 툴이나 라이브러리가 Yarn Berry와 호환되지 않는 경우가 있습니다. 이런 경우에는 PnP 패치나 플러그인을 사용하거나, loose 모드나 nodeLinker 옵션을 사용하여 문제를 해결할 수 있습니다.

따라서 Yarn Classic에서 Yarn Berry로 마이그레이션할 때 체크리스트는 다음과 같이 작성할 수 있습니다:

- [ ] yarn set version berry 명령어 실행
- [ ] 설정 파일 변환
- [ ] yarn install 명령어 실행
- [ ] 호환성 문제 해결

References

(1) Migration | Yarn - Package Manager (2) Feedback on Yarn 3 migration from Yarn classic · Discussion #3448 · yarnpkg/berry ... (3) yarnpkg/yarn: The 1.x line is frozen - GitHub

사용 방법이나 플래그가 변경(deprecated)된 일부 명령어들

Yarn Berry에서 모든 명령어들이 바뀐 것은 아니지만, 일부 명령어들은 사용 방법이나 플래그가 변경되었습니다. 예를 들어:

  • yarn install 명령어는 이제 --frozen-lockfile 플래그가 기본값입니다. 만약 의존성을 업데이트하고 싶다면 --check-cache 플래그를 사용해야 합니다.
  • yarn start, yarn run, yarn add 등의 명령어는 이제 Node 환경 변수를 주입하기 위해 yarn node를 사용해야 합니다. 예를 들어, yarn node index.js 또는 yarn node -p "process.versions.pnp"와 같이 사용할 수 있습니다.
  • yarn global 명령어는 이제 존재하지 않습니다. 대신에 Yarn Berry에서 제공하는 코어 패키지나 플러그인 패키지를 설치하고 싶다면 yarn dlx 명령어를 사용할 수 있습니다.

따라서 바뀌기 전의 명령어 -> 바뀐 명령어 형식의 리스트는 다음과 같이 작성할 수 있습니다:

- yarn install -> yarn install --check-cache
- yarn start/run/add ... -> yarn node start/run/add ...
- yarn global ... -> yarn dlx ...

새롭게 생긴 명령어 리스트는 다음과 같이 작성할 수 있습니다:

- yarn set version: Yarn 버전을 설정하거나 업데이트합니다.
- yarn up: 의존성을 업데이트합니다.
- yarn patch: 의존성에 패치를 적용합니다.
- yarn plugin: Yarn 플러그인을 관리합니다.
- yarn workspaces: 워크스페이스에 관한 정보를 출력합니다.

사라지거나 더 이상 권장하지 않는 명령어 리스트는 다음과 같이 작성할 수 있습니다:

- yarn global: 글로벌 패키지 설치 기능이 제거되었습니다.
- yarn upgrade: 대신에 yarn up을 사용하세요.
- yarn upgrade-interactive: 대신에 \--interactive 옵션을 추가하세요.

References

(1) GitHub - yarnpkg/berry: 📦🐈 Active development trunk for Yarn ⚒ (2) CLI Introduction | Yarn (3) Migration | Yarn - Package Manager

Migration from Yarn Classic to Yarn Berry (Example)

리액트 네이티브 라이브러리의 package.json 내용을 Yarn Berry로 마이그레이션하기 위해서는 다음과 같은 절차를 따라야 합니다:

  • yarn set version berry 명령어를 실행하여 Yarn 버전을 2로 설정합니다. 이 명령어는 .yarnrc.yml 파일과 .yarn/releases/yarn-berry.cjs 파일을 생성합니다.
  • 만약 .npmrc 또는 .yarnrc 파일을 사용하고 있다면, 새로운 형식으로 변환해야 합니다. 예를 들어, registry "https://registry.yarnpkg.com"npmRegistryServer: "https://registry.yarnpkg.com" 로 바뀌어야 합니다.
  • .yarnrc.yml 파일에 nodeLinker: node-modules 를 추가합니다. 이 옵션은 기존의 node_modules 폴더를 사용하도록 설정합니다. 만약 PnP 기능을 사용하고 싶다면 이 옵션을 생략할 수 있습니다.
  • yarn install 명령어를 실행하여 의존성을 설치하고 lock 파일을 업데이트합니다.

따라서 수정된 package.json 내용은 다음과 같습니다:

{
  "name": "@dongminyu/react-native-step-counter",
  "version": "0.1.11",
  "private": false,
  "summary": "It is a multi-platform library that combines CoreMotionSensor from iOS with SensorEventListener from Android.",
  "description": "This library provides an interface for tracking the number of steps taken by the user in a React Native app.",
  "main": "lib/commonjs/index",
  "module": "lib/module/index",
  "types": "lib/typescript/index.d.ts",
  "react-native": "src/index",
  "source": "src/index", // files 필드에 .yarn 폴더와 .pnp.js 파일을 추가합니다 // 만약 PnP 기능을 사용하지 않는다면 .pnp.js 파일은 제외할 수 있습니다 // .gitignore 파일에도 동일한 내용을 추가해야 합니다 // https://github.com/yarnpkg/berry/blob/master/.gitignore#L8-L9 // https://github.com/yarnpkg/berry/blob/master/package.json#L16-L17 // https://github.com/yarnpkg/berry/blob/master/.npmignore#L1-L2 // 참고하세요
  "files": [".yarn/**/*", ".pnp.js"],
  "scripts": {
    // yarn install 명령어에 \--check-cache 플래그를 추가합니다
    // https://yarnpkg.com/getting-started/migration/#update-your-install-script-if-needed
    // 참고하세요
    "bootstrap": "yarn install --check-cache && yarn example install && yarn example pods && yarn example gradle"
  }
}

References

(1) Migration | Yarn - Package Manager (2) GitHub - yarnpkg/berry: 📦🐈 Active development trunk for Yarn ⚒ (3) Yarn: How to upgrade yarn version using terminal?

Make Alias to Make Easy to Use Yarn Berry

Yarn Berry에서는 기본적으로 명령어에 대한 별칭(alias) 기능을 제공하지 않습니다. 이는 Yarn의 핵심 철학 중 하나인 단순성을 지키기 위한 결정입니다. 그러나 만약 사용자가 별칭 기능을 원한다면, 다음과 같은 방법들이 있습니다:

  • 쉘(shell)에서 별칭을 설정하는 방법. 예를 들어, alias y= "yarn" 과 같이 쉘 설정 파일에 별칭을 추가할 수 있습니다. 이 방법은 간단하고 편리하지만, 쉘마다 다른 방식으로 설정해야 하고, 모든 팀원이 동일한 별칭을 사용하기 어렵다는 단점이 있습니다.
  • Yarn 플러그인(plugin)을 사용하는 방법. Yarn Berry에서는 플러그인 시스템을 도입하여 사용자가 커스텀 명령어를 만들 수 있도록 지원합니다. 예를 들어, yarn plugin import https://github.com/yarnpkg/berry/raw/master/packages/plugin-aliases/sources/index.ts 와 같이 플러그인을 설치하면 yarn add 대신 yarn a 를 사용할 수 있습니다. 이 방법은 프로젝트별로 일관된 별칭을 사용할 수 있고, Yarn의 기능을 확장할 수 있다는 장점이 있습니다.

References

(1) Adding Command Line Aliases for Yarn | Yarn Blog (2) Useful aliases for Yarn · GitHub (3) [Feature] Command aliases · Issue #3077 · yarnpkg/berry (4) CLI Introduction | Yarn

How to Set Default Option to Yarn Install

리포지토리 내의 yarn 설정파일을 작성해 yarn install의 기본 option을 "--check-cache" 와같은 것으로 디폴트하고 이 외 옵션을 사용하면 그 옵션이 적용되도록 부트스트랩할 수 있나?

Yarn Berry에서는 .yarnrc.yml 파일을 사용하여 Yarn의 내부 설정을 관리할 수 있습니다. 이 파일은 프로젝트의 루트 디렉토리에 위치해야 하며, 다음과 같은 형식으로 옵션을 지정할 수 있습니다:

yarnPath: ".yarn/releases/yarn-berry.cjs"
nodeLinker: "pnp"
initFields:
  license: "MIT"
  version: "1.0.0"
npmRegistryServer: "https://registry.yarnpkg.com"
npmPublishRegistry: "https://registry.npmjs.org"

이 예시에서는 yarn install 의 기본 옵션을 --check-cache 로 설정하고 싶다면, 다음과 같이 installConfig.checkCache 항목을 추가하면 됩니다:

installConfig:
  checkCache: true

이렇게 하면 yarn install 명령어를 실행할 때마다 캐시된 파일들의 무결성을 검사하게 됩니다. 만약 다른 옵션을 사용하고 싶다면 명령어에 직접 추가하면 됩니다. 예를 들어, --immutable 옵션을 사용하고 싶다면 yarn install --immutable 과 같이 입력하면 됩니다.

References

(1) Configuration options | Yarn - Package Manager (2) yarn config | Yarn (3) Migration | Yarn - Package Manager

How to Update Dependencies with Yarn Berry

나는 라이브러리 전체 의존성을 업데이트하는 'yarn update --audit --latest'를 자주 사용하는데 같은 방법으로 yarn up에 적용할 수 있나?

Yarn Berry에서는 yarn up 명령어를 사용하여 라이브러리의 의존성을 업데이트할 수 있습니다. 이 명령어는 package.json 파일에 있는 버전 범위를 기준으로 업데이트를 수행하며, 다음과 같은 옵션을 사용할 수 있습니다:

  • --latest: 버전 범위와 상관없이 최신 버전으로 업데이트합니다.
  • --caret, --tilde, --exact: 업데이트 후에 package.json 파일에 적용할 버전 범위의 접두사를 지정합니다.
  • --audit: 의존성을 업데이트하기 전에 보안 취약점을 검사합니다.
  • 따라서, 질문하신 명령어와 동일한 기능을 하려면 다음과 같이 입력하면 됩니다:
yarn up --audit --latest

References

(1) GitHub - yarnpkg/berry: 📦🐈 Active development trunk for Yarn ⚒ (2) Yarn: How to upgrade yarn version using terminal? (3) yarn upgrade | Yarn

How to Reset Yarn and Node.js Cache

Yarn의 로컬 캐시를 리셋하는 방법은 다음과 같습니다:

  • yarn cache clean 명령어를 사용하여 현재 프로젝트의 로컬 캐시를 삭제합니다.
  • yarn cache clean --mirror 명령어를 사용하여 전역 캐시를 삭제합니다.
  • yarn cache clean <module_name> 명령어를 사용하여 특정 모듈의 캐시만 삭제합니다.

Node.js의 로컬 캐시를 리셋하는 방법은 다음과 같습니다:

  • npm cache clean --force 명령어를 사용하여 전역 캐시를 삭제합니다.
  • npm cache verify 명령어를 사용하여 캐시의 무결성을 검사하고 오래된 데이터를 제거합니다.

Yarn Berry의 캐시를 삭제하는 방법은 다음과 같습니다:

  • .yarn/cache 폴더를 삭제하면 로컬 캐시를 삭제할 수 있습니다. 이 폴더는 프로젝트의 루트 디렉토리에 위치하며, yarn install 명령어를 실행할 때마다 다시 생성됩니다.
  • .yarn/berry/cache 폴더를 삭제하면 전역 캐시를 삭제할 수 있습니다. 이 폴더는 Yarn Berry의 설치 경로에 위치하며, PnP 기능을 사용할 때 패키지 파일을 읽어오는 역할을 합니다. 이 폴더도 yarn install 명령어를 실행할 때마다 다시 생성됩니다.

References

(1) yarn cache clean | Yarn - Package Manager (2) yarn cache | Yarn (3) yarnpkg - How to clear cache in Yarn? - Stack Overflow (4) yarn cache | Yarn (5) What is the .yarn/berry/cache folder for when using Yarn 3? (6) Offline Cache | Yarn - Package Manager

What is PnP Feature in Yarn Berry?

Yarn Berry의 PnP 기능은 node_modules 디렉토리를 사용하지 않고 패키지 의존성을 관리하는 방식입니다. PnP는 package.json 파일을 기반으로 의존성 트리를 생성하고,.yarn/cache 폴더에 의존성 정보를 저장하고.pnp.cjs 파일에 의존성을 찾을 수 있는 정보가 기록됩니다. 이렇게 하면 패키지 설치 시간과 디스크 공간을 절약할 수 있습니다. 또한 PnP는 zero install이라는 기능을 지원하여 프로젝트를 복제할 때 별도의 설치 과정 없이 바로 실행할 수 있습니다.

References

(1) Yarn Berry 도입 (feat. pnp) (2) [Yarn berry] pnp (Plug And Play), Zero Install을 위한 Dependency 문제 ... (3) [Yarn berry] pnp(Plug And Play), Zero Install을 위한 Dependency 문제 해결하기 (4) Yarn Berry의 PnP(Plug'n'Play) 살펴보기

Is there Some Issue can happen If I don't migrate to Yarn Berry?

Yarn Classic 버전을 계속해서 대규모 상업적 서비스에 이용할 때 발생할 수 있는 관련 이슈에는 다음과 같은 것들이 있습니다.

  • nodejs 대신 node 이름을 사용하는 일부 배포판에서 yarn이 node가 설치되지 않았다고 불평할 수 있습니다.
  • node_modules 디렉토리가 프로젝트마다 중복되어 디스크 공간을 낭비하고 설치 시간을 늘릴 수 있습니다.
  • 프로젝트가 내 컴퓨터에서 작동하지 않는다는 문제를 일으킬 수 있는 의존성 해결 방식의 한계가 있습니다.
  • Yarn 2와 비교하여 새로운 기능이나 개선사항이 제공되지 않을 수 있습니다.

References

(1) Installation | Yarn (2) Migration | Yarn - Package Manager (3) Issues · yarnpkg/yarn · GitHub

Yarn Berry is not compatible with Yarn Classic?

Yarn 2가 기존의 프로젝트 구조나 설정과 충돌할까봐 걱정 하시는군요. Yarn 2가 기존의 프로젝트 구조나 설정과 충돌할 수 있는 이유 중 하나는 Yarn 2가 새로운 Plug'n'Play (PnP) 아키텍처를 사용하기 때문입니다. PnP는 패키지를 설치하는 node_modules/ 폴더를 없애고 대신 .pnp.js 파일을 생성하여 의존성을 관리합니다. 이 방식은 디스크 공간과 설치 시간을 절약하고 의존성 해결 방식을 개선하지만, node_modules/ 폴더에 의존하는 일부 IDE나 툴과 호환되지 않을 수 있습니다. 하지만 걱정하지 마세요. Yarn 2는 nodeLinker: node-modules 옵션을 통해 기존의 node_modules/ 폴더를 유지할 수 있도록 지원합니다. 또한 Yarn 2는 PnP와 호환되도록 만들어진 다양한 IDE나 툴의 플러그인들을 제공합니다. 따라서 Yarn 2로 마이그레이션하더라도 기존의 프로젝트 구조나 설정과 크게 충돌할 가능성은 낮습니다.

References

(1) It’s 2021, and You Should Switch to Yarn 2 - Atomic Spin (2) Introducing Yarn 2 ! 🧶🌟 (3) What's the problem with Yarn 2? - Medium

Difference between Yarn version 2._ and Yarn version 3._

Yarn version 2.*와 Yarn version 3.*에는 몇 가지 차이점이 있습니다.

  • Yarn 3는 Yarn 2보다 성능이 향상되었습니다. 예를 들어, yarn install 명령어의 실행 시간이 약 30% 단축되었습니다.
  • Yarn 3는 esbuild를 사용하여 TypeScript 파일을 컴파일할 수 있습니다. 이 기능은 yarn plugin import typescript 명령어로 설치할 수 있으며, yarn tsc 명령어로 실행할 수 있습니다.
  • Yarn 3는 패키지의 버전 범위를 더 유연하게 지정할 수 있도록 해줍니다. 예를 들어, ^1.0.0 || ^2.0.0 과 같은 복합 버전 범위를 사용할 수 있습니다.
  • Yarn 3는 패키지의 의존성을 더 쉽게 수정할 수 있는 patch 프로토콜을 개선했습니다. 예를 들어, patch:foo@npm:1.0.0#./my-changes.patch 과 같은 형식으로 패치 파일을 지정할 수 있습니다.

References

(1) MDH 前端周刊第 13 期:Yarn 3、React Re-rendering、Just JavaScript (2) javascript - Why is "yarn 2" yarn 3.0.1? - Stack Overflow (3) Getting Started with Yarn 3 and TypeScript - Medium (4) It’s 2021, and You Should Switch to Yarn 2 - Atomic Spin

· 약 3분
Dongmin Yu

리눅스 기본 명령어

  • ls: 현재 디렉토리의 파일과 폴더를 보여줍니다. 옵션으로 -a, -l 등을 사용할 수 있습니다.
  • cd: 디렉토리를 이동합니다. 예를 들어 cd /home 으로 홈 디렉토리로 이동할 수 있습니다.
  • pwd: 현재 디렉토리의 경로를 보여줍니다.
  • cp: 파일이나 폴더를 복사합니다. 예를 들어 cp file1 file2file1을 file2로 복사합니다.
  • mv: 파일이나 폴더의 이름을 바꾸거나 이동합니다. 예를 들어 mv file1 file2 는 file1의 이름을 file2로 바꿉니다.
  • rm: 파일이나 폴더를 삭제합니다. 주의해서 사용해야 합니다. 옵션으로 -r, -f 등을 사용할 수 있습니다.
  • cat: 파일의 내용을 화면에 출력하거나 파일을 만듭니다. 예를 들어 cat filenamefilename의 내용을 출력하고 cat > filename 은 새로운 filename 파일을 만듭니다.
  • find: 각종 파일이나 폴더를 검색합니다. 예를 들어 find -name '\*.pl' 은 현재 디렉토리에서 pl확장자를 가진 모든 파일을 찾습니다.
  • ping: 네트워크 연결 상태를 확인합니다. 예를 들어 ping www.google.com 은 구글과의 연결 상태와 시간을 보여줍니다.
  • date: 현재 날짜와 시간을 보여줍니다.

이 외에도 많은 리눅스 명령어가 있으니 참고하시기 바랍니다.

References

  1. 리눅스 명령어 모음 BEST 50 초보자 및 전문가용 - 도라가이드.
  2. 리눅스 기본 명령어 및 Vi 명령어 정리.
  3. [linux] 리눅스 기본 명령어/자주 쓰는 명령어 | 코딩장이.