## Table of Contents

nextjs로 동작하는 일반적인 애플리케이션을 상상하자면, 아래와 같은 요소를 가정하고 개발할 수 있을 것이다.

- api 호출이 있으며, 경우에 따라서 api 호출 과정에서 인증 등의 에러가 발생함
  - 위 인증 에러가 발생할 경우, 원래 가려던 페이지가 아닌 특정 페이지로 이동시켜야 함
- api 호출은 서버사이드, 클라이언트 사이드에서 모두 일어날 수 있으며 두 경우에 모두 위 처리를 해야함

## 1. 에러 정의

먼저 api 호출시 발생할 수 있는 에러에 대해 정의해야 한다. 가장 일반적인 에러는 인증 에러가 있을 것이다. api 호출시 정상적인 응답 (200) 이 아닌, 에러 응답이 왔을 때 에러를 throw 하는 코드를 짜보자.

### error.ts

```typescript
export function isInstanceOfAPIError(object: unknown): object is ApiError {
  return (
    object instanceof ApiError &&
    ('redirectUrl' in object || 'notFound' in object)
  )
}

export class ApiError extends Error {
  redirectUrl: string = ''

  notFound: boolean = false
}

export class NotFoundError extends ApiError {
  name = 'NotFoundError'

  message = '찾을 수 없습니다.'

  notFound = true
}

export class ForbiddenError extends ApiError {
  name = 'ForbiddenError'

  message = '인증처리에 실패했습니다.'

  redirectUrl = '/error'
}

export class AuthError extends ApiError {
  name = 'AuthError'

  message = '인증되지 않은 사용자입니다.'

  redirectUrl = '/auth'
}
```

일단 자바스크립트의 기본 Error Class를 확장해서 우리가 사용할 커스텀 에러를 만들었다.

### api.ts

```typescript
import axios, { AxiosRequestConfig, AxiosResponse } from 'axios'
import { AuthError, ForbiddenError } from './error'

// axios는 400 이상의 status 가 오면 다 에러를 리턴한다.
// 이를 커스텀 할 수 있도록 하여 개발자가 정의한 에러일 때만 에러를 던질 수 있도록 인수를 받는다.
export interface RequestConfig extends AxiosRequestConfig {
  suppressStatusCode?: number[]
}

// axios에 넣을 interceptor.응답에 따라 각각 다른 처리를 한다.
// 굳이 axios가 아니더라도 다른 처리를 할 수 있음.
function AxiosAuthInterceptor<T>(response: AxiosResponse<T>): AxiosResponse {
  const status = response.status

  if (status === 404) {
    throw new NotFoundError()
  }

  if (status === 403) {
    throw new ForbiddenError()
  }

  if (status === 401) {
    throw new AuthError()
  }

  return response
}

export default async function withAxios(requestConfig: RequestConfig) {
  const instance = axios.create()

  instance.interceptors.response.use((response) =>
    AxiosAuthInterceptor(response),
  )

  const response = await instance.request({
    ...requestConfig,
    baseURL: `${!process.browser ? HOST_URL : ''}/api`,
    validateStatus: (status) =>
      [...(requestConfig.suppressStatusCode || [])].includes(status) ||
      status < 500,
  })

  return response
}
```

이제 api는 준비되었으니, 에러를 핸들링할 준비를 해보자.

## 2. 에러 핸들링

`getServerSideProps`는 서버에서 별도로 실행되는 영역이므로, 여기에서 그냥 throw error가 발생하면 nextjs의 에러페이지에 도착해버릴 것이다. 따라서 이를 적절하게 처리해줄 필요가 있다.

### withServerSideProps

```typescript
import { GetServerSideProps, GetServerSidePropsContext } from 'next'
import { ApiError, isInstanceOfAPIError } from './error'

export default function withGetServerSideProps(
  getServerSideProps: GetServerSideProps,
): GetServerSideProps {
  return async (context: GetServerSidePropsContext) => {
    try {
      // getServerSideProps를 평소대로 실행
      // await 를 꼭 붙여서 try catch에서 에러가 잡히도록
      return await getServerSideProps(context)
    } catch (error) {
      // apiError라면
      if (isInstanceOfAPIError(error)) {
        const { redirectUrl, notFound } = error
        // 404로 보내거나
        if (notFound) {
          return {
            notFound: true,
          }
        }
        // 원하는 페이지로 보낸다.
        // https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering 참고
        return {
          redirect: {
            destination: redirectUrl,
            permanent: false,
          },
        }
      }

      console.error('unhandled error', error)

      throw error
    }
  }
}
```

에러를 처리할 higher order component를 만들었으니, 이제는 getServerSideProps를 이 컴포넌트로 감싸주기만 하면 된다.

```typescript
import Head from 'next/head'
import { GetServerSideProps } from 'next'
import styles from '../styles/Home.module.css'
import withGetServerSideProps from '../withServerSideProps'

export default function Home() {
  return (
    <div>
      <h1>결과</h1>
    </div>
  )
}

export const getServerSideProps: GetServerSideProps = withGetServerSideProps(
  async (ctx) => {
    const { status = 200 } = ctx.req?.query
    const response = await fetch(`/api/hello?status=${status}`)

    const result = await response.json()

    return {
      props: {
        result,
      },
    }
  },
)
```

이제 `getServerSideProps`를 사용할 때 `withGetServerSideProps`로 감싸준다면, api에서 에러가 나도 적절하게 redirect 처리를 해줄 것이다.

### 클라이언트

이제 똑같이 클라이언트에서도 처리가 필요하다. 여기에서는 ErrorBoundary를 사용할 것이다.

```typescript
import Router from 'next/router'
import { isInstanceOfAPIError } from './error'
import Error from './pages/error'
import Page404 from './pages/404'

type ErrorBoundaryProps = React.PropsWithChildren<{}>

interface ErrorBoundaryState {
  error: Error | null
}

const errorBoundaryState: ErrorBoundaryState = {
  error: null,
}

export default class ErrorBoundary extends React.Component<
  ErrorBoundaryProps,
  ErrorBoundaryState
> {
  constructor(props: ErrorBoundaryProps) {
    super(props)
    this.state = errorBoundaryState
  }

  static getDerivedStateFromError(error: Error) {
    console.error(error)
    return { error }
  }

  private resetState = () => {
    this.setState(errorBoundaryState)
  }

  private setError = (error: Error) => {
    console.error(error)

    this.setState({ error })
  }

  // 전역 에러 중 캐치하지 못한 에러
  private handleError = (event: ErrorEvent) => {
    this.setError(event.error)
    event.preventDefault?.()
  }

  // promise 중 캐치하지 못한 rejection
  private handleRejectedPromise = (event: PromiseRejectionEvent) => {
    event?.promise?.catch?.(this.setError)
    event.preventDefault?.()
  }

  componentDidMount() {
    window.addEventListener('error', this.handleError)
    window.addEventListener('unhandledrejection', this.handleRejectedPromise)

    Router.events.on('routeChangeStart', this.resetState)
  }

  componentWillUnmount() {
    window.removeEventListener('error', this.handleError)
    window.removeEventListener('unhandledrejection', this.handleRejectedPromise)

    Router.events.off('routeChangeStart', this.resetState)
  }

  render() {
    const { error } = this.state

    if (isInstanceOfAPIError(error)) {
      const { redirectUrl, notFound } = error

      if (notFound) {
        return <Page404 />
      }

      if (redirectUrl) {
        window.location.href = redirectUrl
      }

      return <Error />
    }

    console.log('unhandled client error')

    return this.props.children
  }
}
```

이제 클라이언트와 서버사이드 모두에서 우리가 공통으로 정의한 에러에 대해 처리를 할 수 있게되었다.

## 3. 더 해볼 수 있는 것들

공통으로 정의된 에러페이지에, 메시지만 다르게 띄우고 싶으면 어떻게 해야할까? 사전에 정의된 에러를 쿼리메시지로 보내서 해당 에러에 대한 적절한 메시지로 띄우거나 하는 방법이 있을 것이다. 그리고 이렇게 정의된 에러, 혹은 정의되지 않은 에러가 발생했을 경우 단순히 `console.log` 방식의 에러가 아닌 적절한 logger를 도입해도 좋을 것이다. 물론, 클라이언트와 서버에서의 에러 수집 정책 내지는 방법론이 다를 것이므로 이에 대한 고민도 필요하다.

클라이언트 서버 모두에서 nextjs에서 api에러 핸들링하기

## Table of Contents

## 버퍼란 무엇인가

Nodejs에서 buffer는 raw 바이너리 데이터를 저장할 수 있는 특수한 유형의 객체다. 버퍼는 일반적으로 컴포터에 할당된 메모리 청크, 일반적으로 RAM을 나타낸다. 일단 버퍼크기를 설정하게 되면, 이후에는 변경할 수 없다.

버퍼는 바이트를 저장하는 단위라고 볼 수 있다. 그리고 바이트는 8비트 순서로 이루어져있다. 비트는 컴퓨터의 가장 기본적인 저장 단위이며, 0 또는 1로 이루어져 있다.

Nodejs는 버퍼클래스를 전역 스코프에 expose 하므로 `import`나 `require`를 할 필요가 없다. 이 클래스를 활용하면 raw 바이너리를 조작할 수 있는 함수와 추상화등을 얻을 수 있다.

nodejs의 버퍼를 먼저 살펴보자.

```bash
<Buffer 79 63 65 66 66 6f 72 74>
```

위 예제에서는, 7쌍의 문자를 볼 수 있다. 각 쌍은 버퍼에 저장된 바이트를 나타낸다. 이 버퍼의 크기는 7이다. 그런데, 아까 0과 1로 이루어졌다고 했는데, 보이는 건 그렇지가 않다. 🤔 그 이유는 nodejs는 16진수를 활용하여 바이트를 표현하기 때문이다. 그러므로 모든 마이트는 0~9, a~f를 활용한 두자리로만 나타낼 수 있다.

근데 버퍼는 왜 필요한걸까? 버퍼가 도입되기 이전에는 자바스크립트에서는 이 바이너리 데이터를 처리할 방법이 마땅히 없었다. 속도가 느리고, 바이너리를 처리할 전문적인 도구가 없기 때문에 기존에는 문자열 (string)과 같은 원시 값들을 이용해야 했다. 버퍼는 비트와 바이트를 조금더 쉽게, 그리고 성능에도 유리한 방법으로 조작할 수 있도록 제공되고 있다.

## 버퍼 사용해 보기

버퍼로 무엇을 할 수 있는지 살펴보자.

이제 곧 버퍼에 대해서 알아볼 텐데, 이 처리하는 방식이 자바스크립트의 배열과 유사하다는 것을 알 수 있다. `slice` 라던가 `concat`가 있다거나, `length`로 길이를 구할 수 있다거나. 버퍼는 또한 이터러블 하며 `for-of`에서도 사용할 수 있다.

### 버퍼 생성하기

버퍼를 생성하는 방법은 크게 세가지가 있다.

- `Buffer.from()`
- `Buffer.alloc()`
- `Buffer.allocUnsafe()`

> 과거에는 constructor를 사용하는 방법도 있었지만, 이 방법은 deprecated 되었으므로 쓰지 않는 것이 좋다.

#### `Buffer.from`

이 방법은 buffer를 만드는 가장 뚜렷한 방법이다. string, 배열, `ArrayBuffer` 혹은 또다른 버퍼 인스턴스를 인수로 받을 수 있다. 무엇을 넘겨주냐에 따라서, `Buffer.from()`은 버퍼를 약간씩 다른 방법으로 만든다.

일단 문자열을 넘기면, 그 문자열을 담고 있는 새로운 버저 객체를 만들어 낸다. 기본적으로, 문자열을 `utf-8`로 인코딩한다. [가능한 인코딩 타입들](https://nodejs.org/api/buffer.html#buffer_buffers_and_character_encodings)

```javascript
// utf8로 생성
Buffer.from('yceffort')
// <Buffer 79 63 65 66 66 6f 72 74>

Buffer.from('19881024', 'hex')
// <Buffer 19 88 10 24>
```

또한 바이트의 배열을 파라미터로 넘길 수 있다.

```javascript
Buffer.from([0x79, 0x63, 0x65, 0x66, 0x66, 0x6f, 0x72, 0x74])
// <Buffer 79 63 65 66 66 6f 72 74>
```

> `0xNN`은 `0x` 뒤의 값이 16 진수라는 것을 의미한다.

만약 `Buffer.from()`에 또다른 버퍼를 넘긴다면, nodejs는 해당 버퍼를 복제해서 또다른 버퍼를 만든다. 그리고 이렇게 생성된 새로운 버퍼는 메모리의 다른 공간에 저장해두기 때문에, 독립적으로 수정할 수 있다.

```javascript
const buffer1 = Buffer.from('yceffort')
const buffer2 = Buffer.from(buffer1)

buffer2[0] = 0x63

console.log(buffer1.toString()) // yceffort
console.log(buffer2.toString()) // cceffort
```

#### Buffer.alloc

`.alloc()` 메소드는 데이터를 채울 필요가 없는 빈 버퍼를 생성하고 싶을 때 유용하다. 기본적으로, 숫자를 인수로 받으며 받은 숫자만큼의 빈 사이즈의 버퍼를 생성한다.

```javascript
Buffer.alloc(7)
// <Buffer 00 00 00 00 00 00 00>
```

이렇게 생성한 버퍼에, 원하는 데이터를 채울 수 있다.

```javascript
const buffer = Buffer.alloc(1)
buffer[0] = 0x78
buffer.toString('utf-8')
// 'x'
```

#### Buffer.allocUnsafe()

`allocUnsafe`를 사용하면 버퍼안의 내용을 검사하고 0으로 채우는 기본적인 작업을 스킵한다. 버퍼는 이전 데이터를 포함 할 수 있는 메모리 ("unsafe" 이라는 뜻은 여기에서 나온 것이다) 영역에 할당한다. 예를 들어, 다음 코드를 실행하면 실행 시마다 매번 일부 랜덤 데이터를 프린트 하게 된다.

```javascript
const buffer = Buffer.allocUnsafe(100)
buffer.toString('utf-8')
// '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
```

도대체 쓸 곳이 없어 보이는 이 메소드는 안전하게 할당된 버퍼를 복사하는 케이스에 사용해 봄직하다. 복사된 버퍼를 완전히 덮어 써버리기 때문에 모든 이전 바이트가 예측 가능한 데이터로 대체할 수 있게 된다.

```javascript
const originalBuffer = Buffer.from('hello, yceffort')
const copyBuffer = Buffer.allocUnsafe(originalBuffer.length)
originalBuffer.copy(copyBuffer)
copyBuffer.toString()
// 'hello, yceffort'
```

일반적으로, `allocUnsafe()`는 오로지 적절한 이유가 있을 때만 사용하는 것이 좋다. (성능 최적화 라던가) 이 메소드를 사용할 때는, 내부에 예측하지 못한 데이터로 채워지지 않도록 꼭 적절한 데이터로 채워야 한다. 그렇지 않으면 원치 않는 정보가 밖으로 새내어갈 수 도 있다.

### Buffer를 쓰기

`Buffer.write()`를 사용하여 일반적으로 버퍼에 데이터를 쓰는 작업을 진행한다. 기본적으로, `utf-8`로 별도 오프셋 없이(버퍼 맨처음 부터) 작성된다. 이 메소드를 쓰면, 버퍼를 사용하는데 들었던 바이트를 리턴한다.

```javascript
const buffer = Buffer.alloc(7)

buffer.write('yceffort')
buffer.write('babo yceffort')

buffer.toString()
// 'babo yc', 7로 생성했기 때문에 이후 데이터는 잘린다.
```

한가지 명심해야할 것은, 모든 글자가 하나의 바이트에 저장되지 않는 다는 것이다.

```javascript
const wrongEmojiBuffer = Buffer.alloc(1)
wrongEmojiBuffer.write('🥸')
wrongEmojiBuffer.toString()
// \x00'
```

utf-8 인코딩은 최대 4바이트의 문자를 지원한다. 버퍼 크기는 이후에 수정할 수 없으므로, 항상 버퍼에 작성하는 내용과 버퍼의 크기와 작성하려는 콘텐츠의 크기를 항상 염두해 두어야 한다.

```javascript
const emojiBuffer = Buffer.alloc(4)
emojiBuffer.write('🥸')
emojiBuffer.toString()
// '🥸'
```

버퍼를 쓰는 또다른 방법은 버퍼의 특정위치에 바이트를 추가하는, 즉 배열에 요소를 넣는것 과 같은 방법을 사용하는 것이다. 1바이트를 초과하는 데이터는 버퍼의 각 위치에서 분해해서 설정해야 한다.

```javascript
const buff = Buffer.alloc(5)

buff[0] = 0x68 // 0x68 is the letter "h"
buff[1] = 0x65 // 0x65 is the letter "e"
buff[2] = 0x6c // 0x6c is the letter "l"
buff[3] = 0x6c // 0x6c is the letter "l"
buff[4] = 0x6f // 0x6f is the letter "o"

console.log(buff.toString())
// hello

// 2바이트 이상의 글자를 한 버퍼에 넣는 다면 실패한다.
buff[0] = 0xc2a9

console.log(buff.toString())
// --> '�ello'

buff[0] = 0xc2
buff[1] = 0xa9

console.log(buff.toString())
// ©llo
```

배열 처럼 쓸 수 있는 건 재밌는 일이지만, 가능하면 `Buffer.from`을 사용하는 것이 좋다. 입력 값의 길이를 관리하는 것은 굉장히 어렵고, 코드의 복잡성을 키울 수 있다. `from()`을 사용하면 별 걱정 없이 쓸 수 있으며, 입력이 너무 큰 경우 입력이 잘 되지 않는 지등을 확인하여 처리할 수 있다.

### 버퍼 순회하기

모던 자바스크립트에서 순회를 하는 방식으로, 버퍼도 마찬가지로 순회 할 수 있다.

```javascript
const buffer = Buffer.from('yceffort')
for (const b of buffer) {
  console.log(b.toString(16))
}
// 79
// 63
// 65
// 66
// 66
// 6f
// 72
// 74
```

`.entries()` `.values()` `.keys()`도 물론 가능하다.

```javascript
const buffer = Buffer.from('yceffort')
const copyBuffer = Buffer.alloc(buffer.length)
for (const [index, b] of buffer.entries()) {
  copyBuffer[index] = b
}

console.log(copyBuffer.toString())
// yceffort
```

## 버퍼와 TypedArrays

자바스크립트에서는, 메모리를 `ArrayBuffer` 클래스를 사용하여 할당 할 수 있다. 이 `ArrayBuffer` 객체를 직접 조작하는 경우는 거의 없다. 대신 이 `ArrayBuffer`를 참조하는 "view" 객체 집합을 사용한다. 이 객체 집합으로는 다음과 같은 것들이 있다.

- `Int8Array`
- `Uint8Array`
- `Uint8ClampedArray`
- `Int16Array`
- `Uint16Array`
- `Int32Array`

> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray#typedarray_objects

그리고 `TypedArray`가 있다. 이는 위에 나열된 모든 뷰 객체를 포괄하는 용어다. 모든 뷰 객체는 프로토타입을 통해 `TypedArray` 메소드를 상속한다. `TypedArray` 생성자는 글로벌로 노출되지 않으므로 `new TypedArray()`와 같은 방법을 사용해야 한다.

nodejs에서는 Buffer 클래스로 생성된 객체도 `Unit8Array` 인스턴스다. 여기에는 아주 작은 차이점이 존재한다.

> https://nodejs.org/api/buffer.html#buffer_buffers_and_typedarrays


nodejs로 백엔드하는 회사 찾습니다

nodejs의 버퍼 이해하기

개발자는 코드로 돈을 벌지, 테스트로 버는 사람이 아니다. 따라서 테스트는 주어진 신뢰에 도달할 수 있게 최대한 간결하게 작성되어야 한다.

좋은 자바스크립트 테스트 코드를 짜는 방법

## Table of Contents

## Introduction

npm은 자바스크립트 개발자에게 있어 한 줄기 빛 같은 도구다. 자바스크립트 프로젝트를 시작한다고 하면, 열에 아홉은 `npm init` 명령어와 함께 시작한다. 그렇게 생성된 `package.json`에 필요한 npm 패키지를 하나 둘 씩 설치해 나가다 보면 어느새 프로젝트가 완성되어 있다. `don't reinvent the wheel again` 이라는 개발의 오랜 격언 처럼, 개발자가 필요로 하는 자바스크립트 패키지들 대부분은 npm에 존재하고 그리고 손쉽게 설치한다. 그러나 설치는 쉽게 하지만, 쉽게 설치되는 만큼 그 안에 개발 부채가 쌓이고 있다는 사실은 다들 간과하고 있는 것 같다. 점점 커져가고 있는 `package.json`에서는 무슨 일이 일어날 수 있을까? 그리고 이를 방지하기 위해서는 어떻게 해야할까?

## 1. 설치하고자 하는 패키지의 dependencies를 파악하자

아래 package.json을 살펴보자.

```json
{
  "name": "sample",
  "dependencies": {
    "react-scripts": "^3.4.2"
  },
  "devDependencies": {
    "eslint": "^7.32.0"
  }
}
```

`create-react-app`으로 react 프로젝트를 시작한다면 `react-scripts`가 설치되어 있을 것이다. 그리고 코딩 컨벤션을 위해 `eslint`를 설치할 수도 있다. 그러나 위 dependencies는 한가지 문제가 있다.

```
➜  playground npm list eslint
playground@ /Users/yceffort/private/playground
├── eslint@7.32.0
└─┬ react-scripts@3.4.4
  ├─┬ @typescript-eslint/eslint-plugin@2.34.0
  │ ├─┬ @typescript-eslint/experimental-utils@2.34.0
  │ │ └── eslint@6.8.0 deduped
  │ └── eslint@6.8.0 deduped
  ├─┬ @typescript-eslint/parser@2.34.0
  │ └── eslint@6.8.0 deduped
  ├─┬ babel-eslint@10.1.0
  │ └── eslint@7.32.0 deduped
  ├─┬ eslint-config-react-app@5.2.1
  │ └── eslint@6.8.0 deduped
  ├─┬ eslint-loader@3.0.3
  │ └── eslint@6.8.0 deduped
  ├─┬ eslint-plugin-flowtype@4.6.0
  │ └── eslint@6.8.0 deduped
  ├─┬ eslint-plugin-import@2.20.1
  │ └── eslint@6.8.0 deduped
  ├─┬ eslint-plugin-jsx-a11y@6.2.3
  │ └── eslint@6.8.0 deduped
  ├─┬ eslint-plugin-react-hooks@1.7.0
  │ └── eslint@6.8.0 deduped
  ├─┬ eslint-plugin-react@7.19.0
  │ └── eslint@6.8.0 deduped
  └── eslint@6.8.0
```

`react-scripts@3.4.4`에서는 `eslint@6`를 사용 중인데, 이를 무시하고 `eslint@7`을 설치했을 경우 위와 같이 의도치 않는 패키지 트리를 생성하게 된다. `node_modules`에는 `eslint@7`이 설치될 것이고, [eslint의 7에는 breaking change](https://eslint.org/docs/user-guide/migrating-to-7.0.0)가 있기 때문에 잠재적으로 문제가 될 수 있다.

`react-scripts`를 `4.x`로 업데이트 하기로 결정했다고 가정해보자. 단순히 버전업만 하면 될까? 그렇지 않다. 버전업 하기전에는 패키지의 CHANGE LOG와 package.json에서의 dependencies의 변경에 주목해야 한다.

https://github.com/facebook/create-react-app/blob/main/CHANGELOG.md#migrating-from-34x-to-400

jest 버전이 24.x에서 26으로 업그레이드 된 것을 볼 수 있다. major 버전 업이기 때문에, jest를 사용하고 있는 테스트 코드에도 문제가 생길 수 있다.

- https://jestjs.io/blog/2020/01/21/jest-25
- https://jestjs.io/blog/2020/05/05/jest-26

그러나 놀랍게도 현재 시간 기준으로 jest의 최신 버전은 27 이다. https://jestjs.io/blog/2021/05/25/jest-27 최신버전을 포기하고 `react-scripts`의 버전에 의존할 것인가? 혹은 무시하고 최신버전을 설치할 것인가?

개발자가 설치하고자 하는 package의 dependencies는 항상 눈여겨 봐야 한다. 설치할 때 뿐만 아니라, major 버전업을 감행할 때 또한 주의를 기울여야 한다. 그리고 dependencies가 복잡한 패키지는 더더욱 설치할 때 주의를 기울여야 한다. 프로젝트에서 꼭 필요로 하는 package 인가? 전체 package의 버전이 여기에 좌우되도 괜찮은가?

## 2. peerDependencies 도 자세히 확인해보자

`peerDependencies`의 중요성을 알기전에, `peerDependencies`의 정의와 `dependencies`의 차이점을 알아야 한다.

> `peerDependencies`: In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.

> https://docs.npmjs.com/cli/v7/configuring-npm/package-json

`peerDependencies`란 실제로 패키지에서 `require`나 `import` 하지는 않지만, 특정 라이브러리나 툴에 호환성을 필요로 할 경우에 명시하는 dependencies다. npm3 부터 6까지는 `peerDependencies`가 자동으로 설치되지 않았고, 설령 버전이 맞지 않더라도 경고 문구만 뜰 뿐이었다. 그러나 npm@7 부터는 기본으로 설치되고, 이 버전이 맞지 않으면 에러도 발생한다.

> In npm versions 3 through 6, peerDependencies were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. As of npm v7, peerDependencies are installed by default.

```json
{
  "name": "playground",
  "dependencies": {
    "react": "16.8.6"
  },
  "devDependencies": {
    "@testing-library/react-hooks": "^7.0.2"
  }
}
```

위 `package.json`을 살펴보자. react 버전은 16.8.6으로 고정되어 있고, `@testing-library/react-hooks`를 설치하려고 시도하고 있다. 그러나 [`@testing-library/react-hooks`는 `peerDependencies`로 `react@>=16.9`를 요구하기 때문](https://github.com/testing-library/react-hooks-testing-library/blob/565c9f80ff969c3b9f20d8b2efdc033996d9ec27/package.json#L78)에 아래와 같이 npm@7 환경에서는 설치가 되지 않는다.

```
➜  playground npm install
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: @testing-library/react-hooks@7.0.2
npm ERR! Found: react@16.8.6
npm ERR! node_modules/react
npm ERR!   react@"16.8.6" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@">=16.9.0" from @testing-library/react-hooks@7.0.2
npm ERR! node_modules/@testing-library/react-hooks
npm ERR!   dev @testing-library/react-hooks@"^7.0.2" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: react@17.0.2
npm ERR! node_modules/react
npm ERR!   peer react@">=16.9.0" from @testing-library/react-hooks@7.0.2
npm ERR!   node_modules/@testing-library/react-hooks
npm ERR!     dev @testing-library/react-hooks@"^7.0.2" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/yceffort/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/yceffort/.npm/_logs/2021-10-06T14_57_04_722Z-debug.log
```

반대로 npm@6 환경에서는 그냥 경고문구만 뜨는 것을 확인할 수 있다.

```
➜  playground npx npm@6 install
npm WARN @testing-library/react-hooks@7.0.2 requires a peer of react@>=16.9.0 but none is installed. You must install peer dependencies yourself.
npm WARN react-error-boundary@3.1.3 requires a peer of react@>=16.13.1 but none is installed. You must install peer dependencies yourself.
npm WARN playground@ No description
npm WARN playground@ No repository field.
npm WARN playground@ No license field.
```

npm@6 환경에서 `peerDependencies`가 단순히 경고 문구만 내뱉고, 설치는 잘된다 하더라도 이를 간과해서는 안된다. 패키지 마다 `peerDependencies`를 버전에 맞게 선언하는데는 이유가 있을 것이고, 이를 지키지 않아서 발생할 수 있는 잠재적인 문제는 모두 오롯이 개발자가 안게 된다.

## 3. 살아있는 패키지를 설치해라

프로젝트에서 꼭 필요로 하는 패키지를 찾았다고 가정해보자. 우리가 필요로 하는 기능도 있고, 사용하기에도 어렵지 않다. 그리고 사용해보니 별 문제도 없었다. 그렇다면 설치해도 될까? 그렇지 않다. 장기적으로 서비스를 안정적으로 관리하기 위해서는 살아있는 패키지, 즉 활발하게 업데이트나 피드백이 오가는 패키지를 설치해야 한다.

우리 프로젝트에서는 [react-swipe-views](https://github.com/sanfilippopablo/react-swipeable-routes)라고 하는 패키지를 설치하여 사용했다. 사용 당시 까지만 하더라도 크게 이슈는 없었지만, 문제는 몇가지 개선사항이 필요해지면서 시작되었다. 수정이 필요한 코드도 찾았고, PR도 열어두었다. 이제 메인테이너의 머지와 버전업만 기다리고 있었는데... 문제는 해당 패키지가 더이상 관리가 되고 있지 않다는 것이었다. 패키지가 살아있기 위해서는 해당 패키지가 꾸준히 관리되고 활발하게 버전업되어야 하지만 그렇지 않으면 죽은 패키지가 되어 버린다. 물론 해당 패키지를 fork하여 개선하는 방법도 있지만 메인테이너의 도움 없이 패키지 코드를 읽고 원하는 형태로 동작하게 만들기 위해서는 상당한 노력이 필요하다.

이는 우리가 오픈소스를 사용하면서 발생하는 일종의 '빚'이라고 생각한다. 관리되고 유지보수 되면 좋지만, 그렇지 않더라도 비난할 수는 없다. 그것이 오픈소스 생태계 이기 때문에.

> 메인테이너를 찾고 있지만, 생각만큼 잘되고 있는 것 같지는 않다.
> https://github.com/oliviertassinari/react-swipeable-views/issues/558

이러한 일들을 막기 위해서는, 다수의 사용자가 사용하고 있는 패키지, star가 많은 패키지를 선택하는 것이 첫번째 방법이다.

![react-swipeable-views](./images/react-swipeable-views.png)

> `react-swipeable-views` 도 4k star에 used 30.6k 이건만,,

그리고 이 패키지를 운영하고 있는 주체가 누구인지도 확인해보고, 메인스트림 브랜치 기준으로 마지막 commit, PR, issue closed 등을 확인해보는 것도 필요하다. 최근까지 패키지가 '살아있다'는 증거를 찾았는가? 그렇다면 설치해도 좋다. 그렇지 않다면 장기적인 관점으로 봤을 때 설치를 재고해봐야 한다.

## 4. 핵심 라이브러리는 직접 구현하자

npm에서 제공되는 다양한 오픈소스 패키지를 활용하여 프로젝트를 꾸미는 것도 좋지만, 프로젝트의 핵심이 되는 코어 기능들은 외부 패키지에 의존하는 것 보다는 자체적으로 만들어서 제공하는 것이 장기적으로 안정적으로 서비스를 운영하는데 도움이된다. 우리가 사용하고 있는 npm 패키지들은 모두 오픈소스임을 명시해야 한다. 오픈 소스이기에 (라이센스만 준수한다면) 무료로 쉽게 이용할 수 있지만, 반대로 언제든지 오픈소스 프로젝트가 중단될 가능성도 존재한다.

> Babel is used by millions, so why are we running out of money?

> ... So, our ask is to help fund our work, via Open Collective and GitHub Sponsors. Though individual contributions do matter (and we deeply appreciate them), we are really looking for more companies to step up and become corporate sponsors, alongside our current sponsors like AMP, Airbnb, Salesforce, GitPod, and others. If it would be better for your company to sustain us in other ways, we are also open to hearing any ideas. Reach out to us directly or by email at team@babeljs.io.

> 프론트엔드 개발자라면 당연히 한번씩은 다 써봤을 babel도 현재 자금난에 시달리고 있다. (그 와중에 눈에 띄는 월 11,000달러 급여...)

> https://babeljs.io/blog/2021/05/10/funding-update

반대로 멀쩡히 잘 쓰고 있던 패키지가 어느 순간 라이센스 정책의 변화로 인해 사용이 어려워 질 수도 있다.

> If you’re a startup, you should not use React (reflecting on the BSD + patents license)

> https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

> 3~4년 전쯤, 리액트가 갑자기 라이센스 정책을 바꾸려고 시도했던 적이 있다. 물론 이는 오픈소스 커뮤니티의 반발로 인해 무산되었다.

물론 프로젝트 전반에 있는 모든 라이브러리, 패키지들을 다 걷어내고 0에서 구현하자는 것은 아니다. 하지만 프로젝트의 핵심 기능, npm 에 존재하는 패키지만으로는 커버가 어려운 기능 등은 직접 구현해서 가지고 있는 것이 좋다. 물론, 내부적으로 패키지화해서 관리한다면 더 좋다. 이러한 이유 때문에 많은 회사들이 내부적으로 관리하는 패키지를 도입하고 있는 추세다. [private package](https://docs.npmjs.com/creating-and-publishing-private-packages)로 관리해도 좋고, 또 오픈소스 커뮤니티의 건강한 성장을 위해 보안상의 위협만 없다면 직접 세상에 알리는 것도 도움이 될 것이다. 그리고 이러한 경험이 개발자를 한단계 성장시키는데 큰 도움이 되리라 믿어 의심치 않는다.


설치와 업데이트 시에는 신중에 신중을.

package.json에 쌓여있는 개발 부채

## Table of Contents

## meme?

![meme1](https://i.redd.it/m41loixjno811.jpg)

![meme2](https://i.kym-cdn.com/photos/images/original/001/382/372/e8b.jpg)

![meme3](https://pbs.twimg.com/media/EPgQXItUcAAQE9V.jpg)

## Introduction

> HTML은 프로그랠밍 언어가 아닙니다.

라는 말은 프론트엔드 개발을 시작하면서 지겹게도 들어보았다. 정말로 프로그래밍 언어가 아니라는 것을 강조하고 싶었던 것인지, 자바스크립트 개발자로서 HTML은 매우 쉬운 언어이기 때문에 차별성을 두고 싶었던건지, 어쨌는 건지 모르겠지만 흔히들 하는 말은 '로직이 없다' 라든가 [튜링 완전(turing completeness)](https://ko.wikipedia.org/wiki/%ED%8A%9C%EB%A7%81_%EC%99%84%EC%A0%84) 이 없다 라든가 등의 논리를 들며 HTML은 프로그래밍 언어가 아니고 마크업 언어라고 주장한다.

> 튜링 완전(turing completeness)이란 어떤 프로그래밍 언어나 추상 기계가 튜링 기계와 동일한 계산 능력을 가진다는 의미이다. 이것은 튜링 기계로 풀 수 있는 문제, 즉 계산적인 문제를 그 프로그래밍 언어나 추상 기계로 풀 수 있다는 의미이다.

그렇다면 정말 프로그래밍 언어로서 HTML은 부족한 점이 있는 것일까? HTML은 정말 프로그래밍 언어가 아닌 것일까? 흔히들 HTML이 프로그래밍 언어로서 무언가 결함이 있거나 부정확하다고 주장할 때 언급되는 논리에 대해서 하나씩 살펴보자.

## HTML이 프로그래밍 언어가 아니라고 하는 주장들

대표적인 주장들을 살펴보자.

### HTML은 마크업 언어지, 프로그래밍 언어가 아니예요.

이 문장 자체는 맞는 것 같아 보이지만 틀렸다고 생각한다. 마크업 언어도 프로그래밍 언어가 될 수 있다. 모든 마크업 언어가 프로그래밍 언어인것은 아니지만, 그럴 수도 있다. 두 개의 벤다이어그램을 그린다면, 약간은 교차하는 모습이 나올 것이다.

변수, 제어, 루프 등을 가지고 있는 마크업 언어 또한 프로그래밍 언어가 될 수 있다. 이는 상호 배타적인 개념이 아니다. 마찬가지로 수학 수식을 그릴 때 사용하는 `Tex` 와 `LaTex` 도 프로그래밍 언어로 볼 수 있는 마크업 언어다. 이 두언어를 가지고 개발을 하는 것은 일반적인 상황은 아니지만, 온라인에서 이러한 예시를 찾아볼 수는 있다.

- https://www.ctan.org/tex-archive/macros/generic/basix
- https://sdh33b.blogspot.com/2008/07/icfp-contest-2008.html

따라서 마크업 언어라고 해서 프로그래밍 언어가 아니라고 하는 것은 잘못되었다. 요점은 두개의 개념이 별개가 아니라는 것이다. 마크업 언어는 프로그래밍 언어일 수 있다. 따라서 HTML이 마크업 언어이기 때문에 프로그래밍 언어가 아니라고 말하는 것은 애초에 전재 조건이 잘못되었다고 볼 수 있다.

### HTML은 로직을 가질 수 없어서 프로그래밍 언어가 아니예요.

로직이란 무엇일까? 튜링 완전과 마찬가지로, 이 주장을 다루기 전에 로직이란 무엇인지 확실히 정의내릴 필요가 있다.

보통 프로그래밍 언어에서의 로직은, 변수나 조건, 루프 등이 있어 사용할 수 있는 것을 의미한다. HTML은 그런데 이러한 것을 사용할 수 없기 때문에 프로그래밍 언어가 아니라고 생각할 수 있다. 하지만 HTML 속성 중에는 변수가 있으며, 변수와 함께 사용할 수 있는 제어구조가 있다. 내부 논리를 제어하는데 자바스크립트나 CSS 가 필요없는 HTML element 가 있다. 여기서 말하는 것은 과거 표준이었던 `<link>` `<noscript>`가 아니다. 사용자의 입력에 따라서 element의 현재 상태와 변수에 값에 따라 조건부 작업을 수행하는 element를 말하는 것이다.

아래 예시를 살펴보자.

```html
<dialog id="dialog1" open>
  <h2>This is an HTML <code>&lt;dialog&gt;</code></h2>
  <p>Dialog</p>
  <p>CSS나 자바스크립트 없이도 닫을 수 있습니다?!</p>
  <form method="dialog" action="#dialog1">
    <button>닫기</button>
  </form>
</dialog>

<details>
  <summary>화살표를 눌러보세요</summary>
  <div>
    <p>띠요옹</p>
    <p>CSS나 자바스크립트 없이도 여닫기를 할 수 있다?!</p>
  </div>
</details>
```

https://6710t.csb.app/

- https://developer.mozilla.org/ko/docs/Web/HTML/Element/dialog
- https://developer.mozilla.org/ko/docs/Web/HTML/Element/summary

따라서 HTML에는 로직이 없어서 프로그래밍 언어가 아니라고 말하는 것도 오해의 소지가 있다. HTML이 사용자의 입력 (클릭)에 따른 결정을 내릴 수 있다. 물론 HTML이 로직을 가지고는 있지만, 데이터를 조작하도록 설계된 다른 언어의 로직과는 본질적으로 다르긴하다. 어쨌거나, HTML이 프로그래밍 언어가 아니라고 말하기 위해서는 더 논리적인 주장이 필요하다.

### 튜링 완전함이 없어서 프로그래밍 언어가 아닙니다.

튜링 완전성이 무엇인지에 대한 논의는 여기저기서 많이 다뤄지고 있기 때문에 굳이 언급하지는 않겠다.

> In the simplest terms, for a language or machine to be Turing complete, it means that it is capable of doing what a Turing machine could do: perform any calculation, a.k.a. universal computation. After all, programming was invented to do math although we do a lot more with it now, of course!

> 언어나 머신이 튜링 완전성을 가지기 위해서는, 튜링 기계가 할 수 있는 것을 똑같이 할 수 있어야 한다. 모든 연산, 즉 보편적인 연산을 수행할 수 있어야 한다. 프로그래밍은 비록 우리가 수학으로 할 수 있는 것 보다 더 많은 것을 하고 있지만, 본질적으로는 수학을 하기 위해서 발명되었다.

> https://notlaura.com/is-css-turing-complete/

대부분의 현대 프로그래밍 언어들이 튜링 완전하기 때문에 사람들은 이를 프로그래밍 언어의 정의로 사용한다. 하지만 사실 튜링 완전성의 정의는 그것이 아니다. 앞서 위키피디아에서 본것 처럼, 튜링 기계를 시뮬레이션 할 수 있는지 여부를 나타내는 것이다. 튜링 완전성은 프로그래밍 언어를 분류하는데 사용할 수 있지만, 튜링 완전성을 가지고 프로그래밍 언어의 정의를 내리는데 사용하기엔 조금 무리가 있다. 예를 들어 마인크래프트나 매직더 게더링도 튜링 완전성을 가지고 있지만, 이를 프로그래밍 언어라고 생각하는 사람은 없다.

튜링 완전성은 아주 과거 일부 사람들이 컴파일 언어와 인터프리터 언어의 차이를 '좋은 언어'의 차이로 나눴던 것과 마찬가지 방식으로 사용되고 있는 것 같다. 백엔드 개발자가, 프론트엔드 개발자를 '가짜 프로그래밍을 하는 사람'으로 평가 절하했던 것과 마찬가지로.

프로그래밍의 정의는 시간에 따라 달라진다. 천공 카드에 어셈블리 코딩을 입력하는 것이 진짜 프로그래밍이라고 주장하는 사람들도 있을 것이다. 보편적이거나, 모세의 그것 처럼 돌로 쓰여진 것은 아무것도 없다.

튜링 완전성은 공정한 기준이라고 볼수도 있지만, 편향되고 주관적인 기준이라고 보는 것이 맞다. 튜링 완전 기계를 생성할 수 있는 언어는 프로그래밍 언어로 판단되는 반면, [유한 상태 기계](https://ko.wikipedia.org/wiki/%EC%9C%A0%ED%95%9C_%EC%83%81%ED%83%9C_%EA%B8%B0%EA%B3%84)를 생성하는 언어는 그렇지 않는 것으로 보는 이유는 무엇인가? 이는 완전히 주관적이라고 생각한다.

마찬가지로, HTML은 튜링 완전하지 않다라고 하는 사람들도 정작 튜링 완전성이 무엇인지 모르거나 이해하지 못하는 것 또한 사실이다. 튜링 완전성은 품질 보증서가 아니다. 프로그래밍 언어를 정의하는 것이 아니라 분류하는 방법이다. 프로그래밍언어는 컴파일/인터프리터일수도, 명령형/선언형 일수도, 절차적이거나/객체지향적 일수도있다. 그리고 마찬가지로 튜링완전할 수도 그렇지 않을 수도 있다.

## 그래서 HTML이 프로그래밍 언어라구요? 아뇨, 더 중요한 것은..

그래서, 프로그래밍 언어가 아니라고 하는 주장을 반박하면 HTML이 프로그래밍 언어가 되는건가? 그런 건 아니다. HTML 표준이 상상 이상으로 발전하거나, 프로그래밍 언어의 정의가 바뀌지 않는 이상 이 논쟁은 아마두 계속 될 것이다.

그러나 중요한 것은 개발자로서 이러한 질문을 받아드릴 경우 심각한 논쟁을 야기하는 것이 아니라, 이러한 논쟁으로부터 개발 생태계를 분리시키는 것이다. 이러한 논쟁은 의도를 숨긴채 쓸데없는 논란을 불러 오기 때문에 매우 경계해야 한다.

> They say you’re not a real programming language like the others, that you’re just markup, and technically speaking, I suppose that’s right. Technically speaking, JavaScript and PHP are scripting languages. I remember when it wasn’t cool to know JavaScript, when it wasn’t a “real” language too. Sometimes, I feel like these distinctions are meaningless, like we built a vocabulary to hold you (and by extension, ourselves as developers) back. You, as a markup language, have your own unique value and strengths.

> 사람들은 여러분이 다른 언어처럼 진짜 프로그래밍 언어라고 말합니다. 이는 단지 마크업이고, 엄밀히 말하면 저는 이것이 옳다고 생각합니다. 더 기술적으로 이야기 하자면, 자바스크립트와 PHP는 스크립트 언어 입니다. 자바스크립트를 아는 것이 자랑이 아니었을 때, 자바스크립트가 진짜 언어 취급을 받지 않았을 때를 기억합니다. 때때로 이런 구별과 논의가 무의미하다고 생각합니다. 마치 이러한 논쟁이 마크업 개발자를 자바스크립트 개발자 뒤로 붙들기 위한 어휘 처럼 느껴집니다. 마크업 언어로서, 여러분 (마크업 개발자 분들)들은 자신만의 고유한 가치와 장점을 가지고 있습니다.

https://css-tricks.com/a-love-letter-to-html-css/

## 결론

HTML 은 프로그래밍 언어인가 아닌가는 별로 중요한 논의도 아니고, 누군가 결정을 내려줘야할 문제도 아니다. 과거 프론트엔드 개발자들이 백엔드 개발자들에게, 나아가 개발자 커뮤니티에서 알게 모르게 무시 당했던 것과 비슷한 느낌이다. HTML과 프로그래밍 언어 이 논쟁은 의미도 없고 아무런 가치도 가지고 있지 않다. 개발을 하는데 개발자가 컴퓨터 공학과 인지, 동양인지 전혀 상관없는 것 처럼 개발자는 개발자 일 뿐이고, HTML은 HTML 일 뿐이다. 웹 생태계, 나아가 현재의 소프트웨어 생태계를 보았을 때 HTML이 차지하는 비중이 결코 작지 않다. HTML은 다른 것들과 마찬가지로 방대한 문서와 광범위한 문법을 가지고 있고, 간단하게 배울 수 있는 것도 아니며, 그 복잡성으로 인해 숙달하는데 있어 몇년이 걸린다. 프로그래밍 언어든 아니든 중요한 것은 HTML이 있다는 것, 그리고 좋은 품질의 웹 애플리케이션을 만들기 위해 반드시 사용해야 한다는 것, 그 것 뿐이다.

## 살펴보기

- https://notlaura.com/is-css-turing-complete/
- https://css-tricks.com/a-love-letter-to-html-css/
- https://css-tricks.com/html-is-not-a-programming-language/


Latest

클라이언트 서버 모두에서 nextjs에서 api에러 핸들링하기

nodejs의 버퍼 이해하기

좋은 자바스크립트 테스트 코드를 짜는 방법

package.json에 쌓여있는 개발 부채

HTML은 프로그래밍 언어인가? 그러나 더 중요한 것은...