
요번에 과제를 진행하며 기존 프로젝트 install 및 새로운 프로젝트 셋팅을 할 경험을 했습니다. 이 과정에서 가장 많이 사용했던 npm에 대해 조금 더 자세히 알아보고 과정에서 궁금했던 점들을 정리해보고자 합니다

## npm?

node package manager. Node.js에서 사용할 수 있는 **모듈들을 패키지화**하여 모아둔 저장소 역할과 패키지 설치 및 관리를 위한 CLI(Command line interface)를 제공한다. 자신이 작성한 패키지를 공개할 수도 있고 필요한 패키지를 검색하여 재사용할 수도 있다.

_npm github을 읽다 알게 되었는데 npm은 node pacakge manager의 줄임말이 아니라고 한다. 따라서 대문자 NPM이 아닌 npm으로 적어달라고ㅋㅋ_

## package.json

`package.json`은 프로젝트 정보와 의존성(dependencies)을 관리하는 문서. npm에 패키지를 배포하고 npm registry에 올리기 위해 반드시 필요한 문서이다.

- 자신의 프로젝트가 의존하는 패키지 목록
- 자신의 프로젝트 버전
- 다른 환경에서도 빌드 할 수 있게 만들어, 다른 개발자도 쉽게 사용할 수 있도록 한다

즉, npm이라는 오픈소스에 패키지를 공유하기 위한 명세이자, 프로젝트의 의존성을 관리를 위한 명세를 관리하는 문서이다.

### tilde, caret

- 틸드(~): x.y.z 중 z 범위 내에서 버전 업데이트
  - ~1.2.3: >=1.2.3 <1.3.0
- 캐럿(^): x.y.z 중 x 이하 하위호환성이 보장되는 범위 내에서 버전 업데이트
  - ^1.2.3: >=1.2.3 <2.0.0

### package-lock.json

`package-lock.json` 파일은 npm을 사용해서 `node_modules` 트리나 `package.json` 파일을 수정하게 되면 자동으로 생성되는 파일이다. 이 파일은 파일이 생성되는 시점의 의존성 트리에 대한 정확한 정보를 가지고 있다.

package.json 파일이 존재하지만 package-lock.json 파일이 필요한 이유는 무엇일까? package.json에는 위에서 설명한 틸드나 캐럿으로 특정 버전이 아닌 버전의 범위를 사용하기 때문이다. 동일한 package.json 파일로 npm install을 실행했지만 패키지의 minor, patch 버전이 배포되면 다른 버전이 설치되는 것이다. 물론 대부분의 경우에는 문제가 없지만 간혹 오류를 일으키는 경우가 있기 때문에 package-lock.json 파일은 의존성 트리에 대한 정확한 정보를 가지고 있다.

## npm ci?

저는 이전까지 주로 기존 프로젝트를 clone받아 package들을 설치할 때 `npm install`을 사용하곤 했다.

새로운 프로젝트를 clone받아 README를 읽다보니 다음과 같이 적혀있었다

![image](https://github.com/prefer2/algorithm/assets/67692759/7239ad01-a285-4530-8ee1-bc43904d32a5)

처음 사용해본 command였다. 내가 알고 있던 ci는 continuous integration의 ci밖에 없어서 찾아보니 여기서 사용되는 ci는 clean install을 뜻한다고 한다.

### npm ci VS npm install

- The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.
- If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.
- `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
- If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
- It will never write to `package.json` or any of the package-locks: installs are essentially frozen.

짧게 요약하자면 npm ci는 package-lock을 기반으로 install을 하기 때문에 version range가 아닌 정확하게 동일한 버전을 설치하게 된다. npm ci를 사용하면 node_modules를 삭제하고 새로 설치한다(때문에 clean install이라는 이름을 가지게 된 것 같다)

### when to use npm ci

자동화된 환경인 테스트 플렛폼, CI, 배포를 위해 사용되거나, 혹은 (node_modules 삭제가 필요한)clean install이 필요할 때 사용하면 된다.

이전 프로젝트에서 캐싱이 필요없는 배포마다 파일들을 삭제해주고, npm install을 한 기억이 난다. 앞으로는 캐싱이 필요하지 않는 경우라면 배포 command 작성을 할 때 ci 명령어를 사용해야겠다.

[https://docs.npmjs.com/cli/v7/configuring-npm/package-json](https://docs.npmjs.com/cli/v7/configuring-npm/package-json)

[https://docs.npmjs.com/cli/v9/configuring-npm/npmrc](https://docs.npmjs.com/cli/v9/configuring-npm/npmrc)

[https://docs.npmjs.com/cli/v10/commands/npm-ci](https://docs.npmjs.com/cli/v10/commands/npm-ci)


어쩌면 나 npm 잘 모르고 있었을지도

알아보자 npm


![image](https://github.com/prefer2/prefer2.dev/assets/67692759/6ff326a7-514c-4f56-bcaa-c7004804f176)


## 무중단 배포

무중단 배포는 말 그대로 서비스가 중단되지 않은 상태로 새로운 버전을 사용자들에게 배포하는 것을 의미한다. 기본적으로 최소 2대의 서버가 필요하다

- 롤링(rolling) 배포
    - 트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식.
    - 새로운 버전의 인스턴스를 생성하고, 로드밸런서에 이 인스턴스를 연결하고 구버전의 어플리케이션이 실행되는 인스턴스를 하나 줄인다
    - 이전 버전이 사용되는 어플리케이션에 대한 연결을 없애고 새로운 버전으로 교체한 후 다시 연결하는 방식
    - 다양한 오케스트레이션 도구에서 지원한다. 많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다는 장점이 있다. 점진적으로 새로운 버전이 사용자에게 출시되므로 배포로 인한 위험성이 줄어든다는 장점도 있다
    - 배포 도중 서비스 중인 인스턴스 수가 줄어들게 되어 각각의 서버가 부담하는 트래픽의 양이 늘어날 수 있다. 트래픽을 잘 파악해야 한다. 또 구버전과 신버전이 동시에 서비스되기 때문에 호환성 문제도 발생할 수 있다
- blue/green 배포
    - 트래픽을 한번에 구버전에서 신버전으로 옮기는 방법. 현재 운영중인 서비스의 환경을 Blue라고 부르고, 새롭게 배포할 환경을 Green이라고 한다.
    - 배포 시점에 로드 밸런서가 트래픽을 Blue에서 Green으로 일제히 전환시킨다
    - 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다
    - 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야 한다
- 카나리(canary) 배포
    - 점진적으로 구버전에 대한 트래픽을 신버전으로 옮기는 것은 롤링 배포 방식과 비슷하지만, 새로운 버전에 대한 오류를 조기에 감지하기 위한 방식이다
    - 소수 인원에 대해서만 트래픽을 새로운 버전에 옮긴 상태에서 서비스한다. 새로운 버전에 이상이 없다라고 여겨진 경우에 모든 트래픽을 신버전으로 옮긴다. 이때 새로운 버전으로 옮기는 기준은 랜덤이다.
    - 새로운 버전으로 인한 위험을 최소화 할 수 있지만, 신/구 버전의 애플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다

공부해야하는 내용이라는 조금 다른 방향으로 공부했지만 이번기회에 한 번 정리해봐서 좋다

## npm install VS npm ci

우선 package.json과 package-lock.json의 차이를 알아야한다. package.json에는 version range로 의존성 목록의 버전을 관리한다(eg. “react”: “^17.0.2”) 이러한 version range로 협업하는 사람마다 서로 다른 node_modules를 생성할 수 있다(각자의 로컬 환경마다 npm, node 버전이 다를 수 있기 때문에)

package-lock.json은 package.json과 다르게 정확한 버전이 명시되어 있다. 이때문에 우리는 협업시에 package-lock.json도 형상관리를 해주는 것이다.

### npm ci(clean install)

- 쓰기 권한이 없다
- package-lock.json이 무조건 존재해야만 하고, 없으면 에러를 낸다
- package-lock.json 파일을 기반으로 의존성을 설치하고, package.json은 버전 매칭 벨리데이션 용도로 사용한다
- node_modules를 삭제한 후, 의존성을 한번에 설치한다

https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci

초기 install은 `npm c`i를 사용하자…!


## RTK

principle of Redux, which is that, everything that changes in your application, including the data and the UI state, is contained in a single object, we call the state or the state tree.

### configureStore

- option 객체가 named되어 있어 읽기 쉽다
- `applyMiddleware`로 미들웨어들을 배열로 전달
- 자동으로 Redux DevTools 사용

기본적으로 redux-thunk 미들웨어를 가지고 있다. 

```jsx
import { configureStore } from '@reduxjs/toolkit'
import usersReducer from './usersReducer'
import postsReducer from './postsReducer'

const store = configureStore({
  reducer: {
    users: usersReducer,
    posts: postsReducer,
  },
	middleware: ...
	enhancers: ...
})

export default store
```

### createSlice

createSlice는 reducer 함수에 기반해서 action type과 action creator를 자동으로 생성해준다.

```jsx
const postsSlice = createSlice({
  name: 'posts',
  initialState: [],
  reducers: {
    createPost(state, action) {},
    updatePost(state, action) {},
    deletePost(state, action) {},
  },
})

// Extract the action creators object and the reducer
const { actions, reducer } = postsSlice
// Extract and export each action creator by name
export const { createPost, updatePost, deletePost } = actions
// Export the reducer, either as a default or named export
export default reducer
```

- initialState
- name: 생성된 action의 prefix
- reducers
- **extraReducers**

slice의 컨셉! 각 slice reducer가 state의 slice를 가지고 있다는 점. 그리고 많은 slice reducer들이 같은 action type에 독립적으로 응답할 수 있다는 점.

extraReducers

비동기 액션에 대한 리듀서? createAsyncThunk를 통해 생성된 action을 다룰 때 주로 사용

reducer와 extraReducer가 모두 같은 action type에 동작한다면 reducer가 사용됨

builder callback

```jsx
// createReducer에서도 builder function 형식을 따라감
// createReducer는 좀 더 편하게 reducer를 만드는 방식

import { createAction, createReducer } from '@reduxjs/toolkit'

interface CounterState {
  value: number
}

const increment = createAction('counter/increment')
const decrement = createAction('counter/decrement')
const incrementByAmount = createAction<number>('counter/incrementByAmount')

const initialState = { value: 0 } as CounterState

const counterReducer = createReducer(initialState, (builder) => {
  builder
    .addCase(increment, (state, action) => {
      state.value++
    })
    .addCase(decrement, (state, action) => {
      state.value--
    })
    .addCase(incrementByAmount, (state, action) => {
      state.value += action.payload
    })
})
```

builder object

- addCase
- addMatcher
- addDefaultCase

https://redux-toolkit.js.org/api/createReducer#usage-with-the-builder-callback-notation

### createAsyncThunk

```jsx
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit'
import { userAPI } from './userAPI'

// First, create the thunk
const fetchUserById = createAsyncThunk(
  'users/fetchByIdStatus',
  async (userId, thunkAPI) => {
    const response = await userAPI.fetchById(userId)
    return response.data
  }
)

// Then, handle actions in your reducers:
const usersSlice = createSlice({
  name: 'users',
  initialState: { entities: [], loading: 'idle' },
  reducers: {
    // standard reducer logic, with auto-generated action types per reducer
  },
  extraReducers: (builder) => {
    // Add reducers for additional action types here, and handle loading state as needed
    builder.addCase(fetchUserById.fulfilled, (state, action) => {
      // Add user to the state array
      state.entities.push(action.payload)
    })
  },
})

// Later, dispatch the thunk as needed in the app
dispatch(fetchUserById(123))
```

https://redux-toolkit.js.org/api/createAsyncThunk

https://blog.hwahae.co.kr/all/tech/6946


## 짧은 회고

조각조각 공부한 내용들이 아까워서 주간 회고를 하려고 한다. 얼마나 오래 갈지는 모르겠지만 한 번 시작하면 몇주라도 더 열심히 메모할테니까….! 글쓰기 습관을 들이자

공통 기술 교육이 끝나고 이제 진짜 팀 교육이 시작되었다. 지금까지 내가 경험해왔던 프론트엔드에만 집중하는 개발이 아닌 조금 더 큰 그림의 학습을 하고 있어 신기하다. 시야를 넓힐 좋은 기회라 생각한다. 새로운걸 공부해서 그런지 간만에 코딩해서 그런지 재미나다.

연수원도 갔다왔겠다 이제 진짜 공부하자 하핳


Tags - npm (2)

알아보자 npm

[WIL] 8월 4, 5주차