Skip to content

Commit

Permalink
Post: npm install, ci 글 추가
Browse files Browse the repository at this point in the history
  • Loading branch information
yiyb0603 authored Nov 8, 2023
2 parents fc64caa + e74d7c9 commit d8c4b8d
Show file tree
Hide file tree
Showing 2 changed files with 132 additions and 5 deletions.
108 changes: 108 additions & 0 deletions posts/npm-install-and-ci.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
---
title: npm install과 npm ci 명령어 알아보기
description: npm 패키지를 설치할때 대표적으로 사용되는 두 명령어를 알아보겠습니다.
category: npm
createdAt: 2023-11-08
thumbnail: https://github.com/yiyb0603/yiyb-blog/assets/50941453/81ec58db-916b-429a-b38f-50e55367e7aa
---

안녕하세요! 오늘은 npm 패키지를 설치할 때 많이 사용되는 두가지 명령어, `npm install``npm ci`란 무엇이고, 차이점은 무엇인지 알아보겠습니다.

## 1. npm install ⚒️

`npm install` 명령어는 npm 패키지를 설치하기 위해서 가장 많이 사용되는 명령어입니다. 별칭 `npm i`를 사용해도 동일하게 작동합니다.

<br />

`npm install`을 사용할 수 있는 방법은 대표적으로 두가지가 있습니다.

첫번째는, `npm install` 명령어 뒤에 설치하려는 `패키지명`을 넣어서 곧바로 패키지를 설치하는 방법입니다. **프로젝트가 진행 중**일때는 해당 방법으로 가장 많이 패키지를 설치하기도 합니다.

```shell
npm install react // react 패키지 설치
```

두번째는, `package.json`에 명시된 모든 패키지를 설치하려고 할때 인데요. 예를들어 React.js로 만들어진 프로젝트를 GitHub에서 clone 하고나서 에디터를 열면, 해당 프로젝트에서 사용되는 패키지들을 모두 다운로드 해야하는 경우가 생깁니다.

이때 `npm install` 명령어를 치면, 해당 명령어가 실행된 프로젝트의 `package.json` 파일에 명시된 모든 npm 패키지를 설치해줍니다. 내가 사용하려는 패키지 명과 버전이 `package.json`에 명시된 경우에는 이 방법을 많이 사용합니다.

```shell
npm install
```

### 1-1. package-lock.json

> 읽기 전에 패키지 버저닝 방법들인 **틸드와 캐럿**에 대해서 알고 계시면 좋습니다.
> https://yiyb-blog.vercel.app/posts/npm-tilde-carrot
만약 `package.json` 파일에 명시된 패키지가 틸드와 캐럿을 사용한 버저닝을 사용했을때 패키지를 로컬에서 설치할때마다 각기 다른 버전이 설치될 수 있는 문제가 있는데요. 특히 협업에서 이런 문제가 많이 발생합니다.

```json
{
"dependencies": {
"next": "^12.2.0"
}
}
```

위처럼 캐럿을 통해 명시된 버전이 있을때, A 개발자는 `12.2.0`, B 개발자는 `12.2.1`, C 개발자는 `12.3.0` 등 각기 다른 버전이 설치되어 예기치 않은 오류를 발생시킬 수 있습니다.

<br />

이처럼 버전이 다르게 설치되지 않도록 해주는 파일이 바로 `package-lock.json` 입니다. `package-lock.json`은 캐럿, 틸드 버저닝의 패키지를 설치할때, 범위 내에서 정확하게 어떤 버전의 패키지를 설치할지 명시해주는 역할을 합니다.

<br />

만약 `package-lock.json`을 소유한 프로젝트에서는 이제 모든 사람이 동일한 버전의 패키지를 설치하며, 위처럼 버전이 각기 다르게 설치되는 현상을 없앨 수 있습니다.

```txt
styled-components@^5.3.6:
version "5.3.6" // ^5.3.6으로 지정된 버전은 5.3.6으로 설치
react@^17.0.2:
version "17.0.2" // ^17.0.2으로 지정된 버전은 17.0.2으로 설치
```

npm, yarn, pnpm에서 사용할 수 있는 lock 파일명은 아래와 같습니다.

| 패키지 매니저 | lock 파일명 |
| ------------- | ----------------- |
| npm | package-lock.json |
| yarn | yarn.lock |
| pnpm | pnpm-lock.yaml |

## 2. npm ci 🧼

`npm ci`**clean install**의 줄임말로, `npm install`과 유사한 패키지 설치 명령어지만 조금의 차이가 있습니다.

<br />

`npm ci``package-lock.json` 파일을 필요로 하며 **(없을경우 오류 발생)** `package.json`과 버전이 매칭되는지 검사하여 `package-lock.json` 파일을 기반으로 패키지들을 설치합니다.

> 한번에 프로젝트의 모든 의존성을 설치하는 역할이므로, 패키지 개별적으로 사용하는 것은 불가능합니다.
<br />

**패키지 버전 범위에서 설치해야하는 버전을 알아내는 연산이 있는 `npm install`과 비교해서 해당 연산이 없기때문에 더 빠른 속도로 설치가 가능**합니다. 그렇기에 Jenkins, GitHub Actions와 같은 `CI 환경`에서 해당 명령어를 사용하면 시간을 단축시킬 수 있을것 같습니다.

<br />

그리고 항상 이전의 `node_modules`를 삭제 후 재설치 한다는 특징이 있는데요. 이는 일관성 있는 패키지 설치 환경을 보장하고, 깨끗한 상태에서 시작합니다.

<br />

npm, yarn, pnpm에서 사용할 수 있는 ci 명령어는 아래와 같습니다.

| 패키지 매니저 | lock 파일명 |
| ------------- | ------------------------------ |
| npm | npm ci |
| yarn | yarn install --frozon-lockfile |
| pnpm | pnpm install --frozon-lockfile |

## 3. 마치며 📌

오늘은 `npm install`, `npm ci`란 무엇이고, 차이점에 대해서 간단하게 알아보았는데요. 처음엔 `npm ci`라는 명령어가 낯설게 느껴졌는데, 자세히 알아보니 기존의 CI 성능에 도움이 되는 좋은 명령어였네요.

<br />

많은분들이 이 글을 보고 도움이 되었다면 좋겠습니다. 이상으로 글을 마치겠습니다. 감사합니다!
29 changes: 24 additions & 5 deletions posts/npm-tilde-carrot.mdx
Original file line number Diff line number Diff line change
@@ -1,42 +1,53 @@
---
title: npm 패키지 버전관리 틸드(~)와 캐럿(^)
description: npm 패키지 버전관리시에 사용되는 틸드(~)와 캐럿(^) 방식에 대해서 알아보겠습니다.
category: Develop
category: npm
createdAt: 2023-05-10
thumbnail: https://github.com/mantinedev/postcss-preset-mantine/assets/50941453/525d2f46-edd9-40f0-9928-6825091f1429
thumbnail: https://github.com/yiyb0603/yiyb-blog/assets/50941453/4c982ca9-7c9a-4a2d-abb9-f203db0c7db2
---

안녕하세요! 오늘은 npm 패키지 버전방식중 <strong>틸드(~)</strong>와 **캐럿(^)** 방식에 대해서 알아보도록 하겠습니다.

<br />

평소에 React, Next.js 등으로 코딩을 할때 자주보는 **package.json** 파일에는 틸드(~)와 캐럿(^) 방식이 많이 사용된것을 볼 수 있는데요, package.json 파일에서 라이브러리 버전들을 관리하면서 이 두 방식에 대해서 궁금증을 가지게 되었고, 알아보게 되었습니다.

![package.json](https://github.com/mantinedev/postcss-preset-mantine/assets/50941453/c3b16389-b06e-497f-b118-28da2e1da7da)

> package.json 파일에 명시된 틸드, 캐럿 버전 방식
## 1. 일반적인 소프트웨어 버저닝(Versioning) ℹ

일반적으로 소프트웨어 배포 후 그에 따른 버저닝을 하게되는데요, 버전 자리마다 각각 **메이저**, **마이너**, **패치**로 통칭됩니다.

![소프트웨어 버저닝](https://github.com/mantinedev/postcss-preset-mantine/assets/50941453/b30c24d3-95e5-41cb-8f4a-a681a19e3220)

> **메이저**: 하위호환이 되지 않을정도의 변화
**마이너**: 하위호환이 되는 범위내에서 **새로운 기능 추가**
**패치**: 하위호환이 되는 범위내에서 **버그 등 Fix**
> **마이너**: 하위호환이 되는 범위내에서 **새로운 기능 추가** 버전
> **패치**: 하위호환이 되는 범위내에서 **버그 등 Fix** 버전
위에서 설명드린 소프트웨어 버저닝 용어들을 알아두면, 아래 글을 읽는데 도움이 될것 같습니다.

## 2. 틸드(~) 버저닝 🦐

틸드 버저닝은 **패치 버전 내에서 버전이 업데이트 되는 방식**을 말합니다.

예를들어, 아래와 같은 틸드 버전이 있을때, 해당하는 범위에 대해서 하위호환성이 가능합니다.

<br />

~1.3.0: `>= 1.3.0` `< 1.4.0`
~1.5.2: `>= 1.5.2` `< 1.6.0`
~2.2: `>= 2.2` `< 2.3`

> 만약 내가 사용하는 React 패키지 버전이 **~17.2.0**으로 되어있다면, 해당 React 버전은 17.2.0 ~ 17.3.0 버전까지 하위호환성이 가능하다는 의미입니다.
## 3. 캐럿(^) 버저닝 🐇

캐럿 버저닝은 **마이너 버전 내에서 버전이 업데이트 되는 방식**을 말합니다.

예를들어, 아래와 같은 캐럿 버전이 있을때, 해당하는 범위에 대해서 하위호환성이 가능합니다.

<br />
^1.3.0: `>= 1.3.0` `< 2.0.0`
^1.5.2: `>= 1.5.2` `< 2.0.0`
Expand All @@ -45,15 +56,23 @@ thumbnail: https://github.com/mantinedev/postcss-preset-mantine/assets/50941453/
> 만약 내가 사용하는 Next 패키지 버전이 **^13.2.0**으로 되어있다면, 해당 React 버전은 13.2.0 ~ 14.0.0 버전까지 하위호환성이 가능하다는 의미입니다.
그러나 캐럿 버저닝 방식에서는 한가지 특징이 있는데, 메이저 버전이 0으로 시작한다면 다르게 동작합니다. 소프트웨어 버저닝 규칙에서 **메이저 버전이 0이라면 pre-release로 간주**되기 때문이죠.

<br />

정식버전(1.0, 2.0 등등)에서는 하위호환성을 고려한 배포가 일어나는 반면, 베타 버전에서는 하위호환성이 되지않는 API 변경이 수시로 일어날 수 있기에 **틸드** 버저닝으로 작동됩니다.

<br />

예를들어, 아래와 같습니다.

^0.3.0: `>= 0.3.0` `< 0.4.0`
^0.5.2: `>= 0.5.2` `< 0.6.0`
^0.2: `>= 0.2.0` `0.3.0`

## 4. 마치며 📌

평소에 틸드와 캐럿 버저닝에 대해서 그냥 보기만 했는데, 이렇게 한번 정리해보고 나니까 머리속에 잘 들어오는거 같네요. 앞으로는 라이브러리 버전에 대해서 깊게 생각 해볼거같네요.

<br />
아무쪼록 긴 글 읽어주셔서 감사합니다!

많은분들께 도움이 되었다면 좋겠습니다. 긴 글 읽어주셔서 감사합니다!

0 comments on commit d8c4b8d

Please sign in to comment.