자바스크립트에서는, promise의 성공과 실패에 따른 콜백을 두가지 방법으로 처리할 수 있다.

```javascript
promise.then(oSuccess, onFailure)
```

```javascript
promise.then(onSuccess).catch(onFailure)
```

이 두 가지는 무엇이 다른걸까?

일단, 각각 성공과 실패에 따른 콜백을 아래와 같이 선언한다고 가정해보자.

```javascript
function onSuccess(value) {
  console.log('Promise has been resolved with value:', value)
}

function onFailure(error) {
  console.log('Promise has been rejected with error:', error)
}
```

먼저, `resolve`의 경우를 살펴보자.

```javascript
Promise.resolve('Hi').then(onSuccess, onFailure) // Promise has been resolved with value: Hi

Promise.resolve('Hi').then(onSuccess).catch(onFailure) // Promise has been resolved with value: Hi
```

특별한 것 없이 둘다 동일한 결과를 보인다.

이번엔 둘다 실패했을 때를 가졍해보자.

```javascript
Promise.reject('Sorry').then(onSuccess, onFailure) // Promise has been rejected with error: Sorry

Promise.reject('Sorry').then(onSuccess).catch(onFailure) // Promise has been rejected with error: Sorry
```

이번에도 동일하다.

이 둘의 차이는, 바로 `resolve`에서 `rejected`가 발생할 때 알 수 있다.

```javascript
function onSuccessButRejected(value) {
  console.log('Promise has been resolved with value:', value)
  return Promise.reject('Oops, Sorry')
}

Promise.resolve('Hi').then(onSuccessButRejected, onFailure)
// Promise has been resolved with value: Hi
// Promise {<rejected>:"Oops, Sorry"}
// Uncaught (in promise) Oops, Sorry

Promise.resolve('Hi').then(onSuccessButRejected).catch(onFailure)
// Promise has been resolved with value: Hi
// Promise has been rejected with error: Oops, Sorry
// Promise {<fulfilled>:undefined}
```

`catch`는, `then` 내부에서도 `reject`가 발생했을 때에도 호출된다.

흐음... 🤔 ...

그렇다면 이건 어떨까?

```javascript
Promise.resolve('Hi').then(onSuccessButRejected).then(null, onFailure)
// Promise has been resolved with value: Hi
// Promise has been rejected with error: Oops, Sorry
```

```javascript
Promise.resolve('Hi').then(onSuccessButRejected).catch(onFailure)
```

와 동일하게 동작하는 것을 알 수 있다. 그렇다면, 둘 중에 무엇을 쓰는게 맞을까?

일반적인, `if/else`구문과, `try/catch`구문을 상상해보자. `if/else`는 내가 예측할 수 있는 경우를 `else`로 처리한다. 반면, `try/catch`는 내가 예측할 수 있는 경우를 포함하여 모든 경우의 수가 `catch`로 처리된다. 따라서, 내가 잠재적으로 처리하고 싶은 명확한 failure가 있다면, `promise.then(oSuccess, onFailure)`를 쓰는 것이 부수효과(side effect)를 방지하는데 있어 도움이 된다. 반면 `promise.catch(onFailure)`는 내가 예측하지 못한 경우를 포함한 모든 에러 - 지정된 작업이 성공처리가 되지 않거나, 비동기 흐름으로 인해 발생하는 오류 - 를 처리할 때 사용하는 것이 좋을 것 같다.

예를 들어, axios를 사용하는 시나리오를 가정해보자.

```javascript
axios
  .get('/api/user/123')
  .then(
    (value) => {
      // 성공
      console.log('user info', JSON.parse(value))
    },
    (error) => {
      // http 에러 (40x, 50x...)
      console.log('http error', error.response.status)
    },
  )
  .catch((error) => {
    // 예측하지 못한 에러
    console.log('Unexpected Error!', error)
  })
```

첫번째 `then`문에서 `resolve`로 정상적으로 응답이 왔을 때 (2xx, 3xx) 처리를 하고 있고, `reject`로 http request에러 (4xx, 5xx)처리를 하고 있다. 그리고 마지막 `catch`문에서는 예측하지 못한 에러를 핸들링하고 있는데, 이 경우는 `JSON.parse`에 실패하는 경우 등의 시나리오에서 호출 될 것이다.


promise.then(f, f) vs promise.then(f).catch(f) 는 무엇이 다를까?

## Table of Contents

## 시작하며

npm, yarn, pnpm 등은 자바스크립트 생태계가 성장하는데 지대한 공헌을 했다. 자바스크립트 영역에서 새로운 솔루션을 끊임없이 쉽게 찾고 이용할 수 있도록 도와주고 있다. 그러나 사용 편의성이라던가, 패키지의 모듈화가 심해진다는 단점 또한 존재한다. 사실, 앞서 소개한 자바스크립트 패키지 관리자들은 실제로 의존성을 제대로 관리하고 있지 못한다.

이 글에서는 결국 의존성 관리자(이하 패키지 관리자라고 칭하겠다)의 근본적인 문제를 해결하고자 하는 것은 아니다. 대신, 하드드라이브의 블랙홀을 막고, 종속성을 제대로 관리할 수 있는 가이드를 제공하고자 한다.

`node_modules`은 패키지가 설치될 수록 커지고 느려지게 된다. 또한 일부 라이브러리에서 패키지 의존성이 심해지면, 이를 사용하는 전세계 모든 사용자들의 작업이 느려지는 결과를 초래한다. 이를 막기 위해 아래 방법을 적용하면 종속성 크기를 점차 줄여나가고, 안정적으로 유지할 수 있다.

## 의존성 제어를 되찾기 위한 방법

이 가이드에서는 주로 `yarn1`에 초점을 맞추고 있지만, 대부분의 많은 권장사항 등이 다른 패키지 관리자에도 적용된다. 한가지 유의할 점은 일부 패키지 관리자의 경우 의존성을 직접 설치하지 않기 위해, 심링크, 하드링크 등의 까다롭고 불투명한 방법을 사용한다는 것이다.

### 1. 의존성 분석

먼저, `node_modules`에 도대체 무슨 패키지들이 설치되어 있는지 이해하는 작업이 필요하다. 여기에서는 다양한 방법을 활용하여 분석해보려고 한다.

- [Disk Inventory X](http://www.derlien.com/)와 `du -sh ./node_modules/* | sort -nr | grep '\dM.*'`를 사용하는 것이다. 이 방법을 사용하면, 현재 `node_modules`의 각 패키지의 크기를 확인해볼 수 있다.

다음은 내 블로그를 위 방법으로 살펴본 결과다.

![disk-inventory-x](./images/disk-inventory-x.png)

```bash
 58M    ./node_modules/typescript
 38M    ./node_modules/@babel
 34M    ./node_modules/tailwindcss
 30M    ./node_modules/next
 22M    ./node_modules/date-fns
 19M    ./node_modules/prettier
 17M    ./node_modules/rxjs
 15M    ./node_modules/@firebase
 11M    ./node_modules/@types
8.1M    ./node_modules/esbuild
7.8M    ./node_modules/@typescript-eslint
7.3M    ./node_modules/protobufjs
7.2M    ./node_modules/core-js-pure
6.4M    ./node_modules/webpack
6.4M    ./node_modules/@google-cloud
6.3M    ./node_modules/google-gax
5.2M    ./node_modules/eslint
4.9M    ./node_modules/lodash
4.6M    ./node_modules/katex
4.5M    ./node_modules/rollup
4.3M    ./node_modules/jsdom
4.1M    ./node_modules/es-abstract
3.6M    ./node_modules/es5-ext
3.2M    ./node_modules/prismjs
3.2M    ./node_modules/caniuse-lite
2.9M    ./node_modules/react-dom
2.6M    ./node_modules/table
2.3M    ./node_modules/@grpc
2.2M    ./node_modules/terser
2.1M    ./node_modules/terser-webpack-plugin
2.0M    ./node_modules/firebase-admin
1.9M    ./node_modules/axe-core
1.8M    ./node_modules/regenerate-unicode-properties
1.8M    ./node_modules/node-forge
1.8M    ./node_modules/@tailwindcss
1.5M    ./node_modules/language-subtag-registry
1.4M    ./node_modules/refractor
1.4M    ./node_modules/eslint-plugin-import
1.3M    ./node_modules/espree
1.3M    ./node_modules/eslint-plugin-react
1.3M    ./node_modules/eslint-plugin-jsx-a11y
1.3M    ./node_modules/acorn-node
1.2M    ./node_modules/node-libs-browser
1.2M    ./node_modules/acorn-globals
1.2M    ./node_modules/@hapi
1.1M    ./node_modules/rollup-plugin-terser
1.1M    ./node_modules/postcss
1.1M    ./node_modules/jest-worker
1.1M    ./node_modules/csstype
1.1M    ./node_modules/ajv
```

- `yarn why <packagename>`: 이 명령어를 사용하면, 해당 패키지가 왜 의존성 트리에 포함되어 있는지 알 수 있다. `npm ls <packagename>` 도 동일하다. 이를 사용하면 버전별로 어떤 패키지가 어떤 의존성으로 설치되어 있는지 알려준다.
- [Packagephobia](https://packagephobia.com/): 패키지가 대략 디스크에서 얼마나 차지하고 있는지 알 수 있다.

![packagephobia-eslint-config-yceffort](./images/packagephobia-eslint-config-yceffort.png)

> 이 패키지가 50메가가 넘다니,, 말세다

https://packagephobia.com/result?p=eslint-config-yceffort

- [Bundlephobia](https://bundlephobia.com/): 앱을 번들링 했을 때 패키지가 얼마나 커지는 지 확인할 수 있다.

![bundlephobia-react](./images/bundlephobia-react.png)

https://bundlephobia.com/package/react@17.0.2

### 2. 미사용 의존성 제거

어떻게 보면 정말 당연한 내용이지만, 많은 프로젝트에서 이러한 죽은 패키지들을 볼 수 있다. 제거하는 것보다는 설치하는게 쉽기 때문이다. 여러 의존성이 존재하고 있을 수도 있고, 사용하지 않는 종속성을 계속 업그레이드 하고 있을 수도 있다. 따라서 패키지에 나열 되어 있는 모든 기본 종속성을 살펴보는 것이 중요하다. 추천해주고 싶은 방법은, `package.json`을 보고, 모든 패키지를 하나씩 살펴본다음 사용하지 않는 것을 제거하는 것이다. 이는 보통 수동으로 하는 것이 좋다. 예를 들어, moment.js를 날리고 이제 date-fns를 사용한다고 가정하자. `moment`가 설치되어 있는지 확인하기 위해서는, 텍스트 에디터의 검색 기능을 사용하거나, [rg](https://github.com/BurntSushi/ripgrep) 패키지를 사용하여 아래 명령어를 날려보자.

```bash
rg '(require\(|from\s+)(?:"|\')moment'
```

그 다음엔 `moment`를 검색해서 현재 사용되고 있는 부분이 있는지 한번더 확인해본다. babel, eslint 또는 jest와 같은 도구의 일부 설정 파일이 해당 모듈을 사용하고 있을 수도 있다.

혹은 [eslint의 룰](https://eslint.org/docs/rules/no-restricted-imports)를 사용해서 패키지 import 시에 경고문을 날려버릴 수도 있다.

```javascript
"no-restricted-imports": [
    "error",
    {
        name: "moment",
        message:
            "moment has been deprecated. use date-fns instead.",
    },
],
```

아무튼, 이제 사용되지 않는 것이 확인되면 `package.json`에서 확실하게 제거하자. 위와 같은 방법을 `dependencies`, `devDependencies`에 반복해서 작업해주자. 또는 [depcheck](https://github.com/depcheck/depcheck)와 같은 도구를 사용해 볼 수도 있다.

### 3. 의존성을 최신화

혹시 '업그레이드 절벽'을 경험해본적이 있는가? 의존성 버전이 너무 뒤쳐져 업그레이드나 마이그레이션에 상당한 노력이 필요하고, 전체 개발 작업속도가 뒤쳐질 수가 있다. (나는 최근에는 husky를 쓰면서 느꼈다) 업그레이드는 조직 전체에 걸쳐 모든 사람의 지속적인 책임으로 하는 것이, 한사람에게 모두 맡겨버리는 것보다는 낫다. 모두가 같이 조금씩 움직여야, 변화를 깨는 것을 덜 주저하게 될 것이다. 한사람이 변화를 주도하는 것은 (리더가 아니라면 더더욱) 너무 힘들다.

모든 의존성을 최신으로 유지하면, 레거시 패키지에서 벗어나고 이후 작업을 더 수월하게 진행할 수 있다. `yarn outdated`나 `yarn upgrade-interactive`를 사용하여 의존성을 확인하면서 최신버전으로 업그레이드할 수 있다. 물론, 이 작업에는 변경사항을 확인하고, 버그 문제를 해결하는 작업이 필요하다. 이를 위해서는 신뢰도를 높일 수 있는 자동화된 테스트가 많을 수록 좋다. 변경사항을 제대로 파악하지 못하고 최신버전을 사용하기 위해 패키지 버전을 올리는 것 만큼 끔찍한 일은 없다.

### 4. 중복되는 패키지는 제거

일부 자바스크립트 패키지 관리자에서 사용되는 알고리즘이 의존성 그래프를 지속적으로 최적화 하지는 않는다. 우리는 `lock`파일이 동일 패키지의 여러버전을 `semver`가 목표로 하는 버전관리에 맞게 패키지를 설치할 책임이 있다고 가정한다. [yarn-deduplicate](https://github.com/atlassian/yarn-deduplicate) 를 사용하면 lock file을 한번더 최적화 할 수 있다. 기본적으로 패키지를 설치하고, 업데이트하거나, 제거할 때마다 `npx yarn-deduplicate yarn.lock`를 하는 것을 추천한다. 또는 CI 과정에 `yarn-deduplicate yarn.lock --list --fail`를 추가하여 지속적으로 이를 확인해볼 수 있다.

이 문제와 관련하여 가장많은 문제를 일으키는 곳은 babel, jest와 같은 모노레포로 이루어진 라이브러리다. 최악의 경우, 여러개의 babel parser, jest package 등이 존재할 수 있다. `yarn-deduplicate`를 사용하면 이러한 문제를 어느 정도 해결할 수는 있지만, 모든 패키지를 업데이트 할 수 있는 확실한 방법은 없다. 이를 해결하기 위해 시도해본 방법은

- 모노레포의 모든 `package.json`를 확인하여 최신버전으로 설치하는 방법
- `yarn upgrade` `yarn upgrade-interactive`
- [yarn resolution](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/)을 활용하여 시멘틱 버전 제한을 덮어쓰고, 모든 패키지를 최신으로 관리

등이 있었다. 하지만 이들 중 어떤 것도 잘 해결하지 못했고 이따금 상황을 악화시키기도 했다. 프로젝트에 단일 babel 버전의 패키지를 설치할 수 있는 확실한 방법은, 수동으로 `yarn.lock`에서 모두 제거한 다음, 다시 처음부터 `@babel/`을 설치하여 의존성 그래프를 다시 그리게 하는 방법이다.

또다른 방법으로는, 패키지의 semver 범위를 직접 탐색하여 해당 패키지에 pull requests를 보내서 의존성을 업그레이드하거나버전을 변경하여 semver버전을 조정하는 것이다.

### 5. 단일 패키지를 명확한 목적에 따라 정리할 것

대규모 프로젝트에서는 동일한 용도의 여러 패키지가 사용될 수 있으며, 동일한 패키지의 여러 major 버전이 설치되어 있을 수도 있다. 규모가 큰 팀에서는, 누군가가 큰 의존성을 들고와서 고작 딱 한번 사용하고는, 번들 크기를 크게 부풀릴 수도 있다. 또는 비슷한 목적의 비슷한 크기의 작은 패키지를 여기저기서 사용하고 있을 수도 있다. 이를 해결하기 위해서는 엄격한 스타일 가이드, 문서화, 코드 리뷰등을 통해 이 문제를 방지할 수 있다. 그러나 최상으로 환경을 준비한다 한들 직접 의존성을 통해 포함된 유사한 기능의 패키지가 존재할 수 있다. 예를 들어, 두개의 패키지에 명령줄 옵션을 해석하는 동일한 기능이지만 다른 패키지가 설치되어 있을 수 있다. 따라서 어떤 패키지가 `node_modules`에 있는지를 분석하고, 각 목적에 따라 하나의 패키지로 정리하는 것이 좋다.

### 6. 필요에 따라 패키지를 포크하여 커스텀

어떤 경우에는 패키지가 너무 유지보수가 안되고 있거나, 너무 급격하게 발전하고 있을 수 있다. 내가 사용하고 있는 오픈소스의 패키지 릴리즈를 기다리기 위해 내 제품을 연기하는 것은 결코 바람직하지 못하다. 이를 해결하기 위한 좋은 방법은 적극적으로 패키지를 포크하여 사용하는 것이다. 포크가 오래 지속될 필요는 없다. 예를 들어, 어떤 작업에 대한 수정을 앞당기기 위해 포크를 하고, 이를 나중에 제거할 수 있다. 이렇게 하면 유지 보수 부담이 생길 수 는 있지만, 프로젝트에서 실행중인 코드의 제어권을 넘겨받을 수 있다.

[Yarn resolution](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/)을 사용하여 기존 패키지를 포크 버전으로 교체할 수 있다.

```javascript
"resolutions": {
  "bloated-package": "npm:@yceffort/not-bloated-package",
  "unmaintained-package": "npm:@yceffort/well-maintained-package"
}
```

포크된 버전은 오래 살려두지 말고, 직접 PR을 날려주는 것이 좋다.

### 7. 의존성의 숫자와 크기를 계속 추적

의존성 크기와 숫자를 한번에 줄이면 좋겠지만, 그것보다는 지속적으로 관리하는 것이 좋다. 개인적으로는, CI 단계에서 `package.json`이나 `yarn.lock`의 변화가 있을 때마다 `node_modules`를 `du -sh node_modules`로 자동으로 확인하는 것이 좋다. PR단계에서 CI를 수행하고, 크기가 커졌다면, 한번쯤 눈길이 갈 것이다.

자동화를 통해 계속해서 확인할 수 있지만, 중요한 것은 동일한 코드베이스로 작업하는 다른 모든 사람들에게 대화하고 책임감을 공유하는 것이 최상의 결과를 가져오는데 도움이 된다. 의존성이 커지면 모든 사람의 작업속도가 느려지거나, 이미 사용하고 있는 유사한 패키지가 설치 될 수 있다는 것을 알리자. 대부분의 경우에는 많은 사람들이 감사하게 생각할 것이다.

예를 들어, 누군가가 `node_modules`의 크기를 두배로 늘리는 패키지를 추가했다고 가정해보자. 간단하게 왜 이것이 옳지 않은지, 이상적이지 않은지를 설명하고 문제를 해결할 다른 두세가지 방법을 제시하기만 하면 또다시 PR을 만들 필요가 없이 해결할 수 있다. 누군가 100줄의 코드를 추가하면, 우리는 코드리뷰를 통해 꼼꼼하게 확인한다. 그러나 패키지에 한줄을 추가하는 것은 최악의 경우 엄청난 크기의 코드를 프로젝트로 가져오고 번들링을 부풀리는데, PR에서는 이게 어떤 영향을 미치는지 알 수 없기 때문에 순식간에 적용되어 버릴 수 있다. 써드파티 종속성에 대한 문제를 버전 컨트롤에서 지속적으로 확인하면 이런 문제를 사전에 방지할 수 있다.

### 다른 방법

yarn에는 [autoclean](https://classic.yarnpkg.com/en/docs/cli/autoclean/) 명령어가 있는데, 이를 통해 제외목록과 일치하는 파일을 자동으로 제거할 수 있다. 이를 통해 프로젝트와 관계없는 예제, 테스트, 마크다운 파일 등을 제거할 수 있다. `yarn autoclean --init`을 실행하고, `.yarnclean`파일을 확인하여 결과를 살펴볼 수 있다. 그러나 이 명령어는 설치하는 동안이 아니라 이미 의존성이 설치된 이후에 실행된다. 이는 yarn의 호출이 몇초 정도 느려질 수 있다는 것을 의미한다. 좋은 기능이지만, 버전 컨트롤에서 `node_modules`를 확인하는 프로젝트에만 사용하는 것이 좋다.


자바스크립트 의존성 관리자(npm, yarn, pnpm)에서 보다 더 의존성 관리 잘하는 방법

자, 흔히 쓰는 import 가 있다.

`module.js`

```javascript
export let data = 5
```

`index.js`

```javascript
import { data } from './module'
```

그런데 만약에 이렇게 import를 해보면 어떨까?

```javascript
const module = await import('./module.js')
const { data: value } = await import('./module.js')
```

첫번째 import 에서 `module.data`를 하는 것은 맨 처음에 import 했던 결과와 완전히 동일 할 것이다. 두번째는, `data`를 `value`라는 새로운 identifier로 할당하고 있다. 그리고 이 동작은 앞선 두 케이스와 묘하게 다르다.

만약에 export 하는 쪽에서 값의 변경이 있다고 가정해보자.

```javascript
export let data = 5

setTimeout(() => {
  data = 10
}, 500)
```

```javascript
import { data } from './module.js'
const module = await import('./module.js')
const { data: value } = await import('./module.js')

setTimeout(() => {
  console.log(data) // 10
  console.log(module.data) // 10
  console.log(value) // 5
}, 1000)
```

또다른 변수로 아예 할당을 해버렸던 3번째 케이스를 제외하고 나머지 모든 값들은 변했다는 것을 알 수 있다. 그렇다. `import`는 일종의 참조 처럼 동작을 한다는 것을 알 수 있다. 사실 이러한 3번째 케이스의 동작은 아래처럼 생각하면 당연하다고 느껴 질 수 있다.

```javascript
const obj = { foo: 'bar' }
const { foo } = obj
obj.foo = 'baz'
console.log(foo) // 'bar'
```

내 개인적으로 봤을 때는 위 케이스, 즉 3번째 케이스가 제일 자연스러워 보인다. 🤔 여전히 자바스크립트는 신비로운 언어다. 근데 잠깐, `import { data }`도 어떻게 보면 분해할당이 아닌가? 근데 이 것은 놀랍게도 분해 할당처럼 동작하지 않는 다는 것을 알 수 있다.

자 정리해보자.

```javascript
// 특정 값을 참조하는 것 처럼 동작하여, 값이 바뀌면 서순에 따라서 그 바뀐 값을 들고 올 수도 있다.
import { data } from './module.js'
import { data as value } from './module.js'
import * as all from './module.js'
const module = await import('./module.js')
// 현재 값을 새로운 변수에 그대로 할당해서, 참조측에서 값이 바뀌든 말든 최초의 값을 계속 간직한다.
let { data } = await import('./module.js')
```

자 그럼, `export default`의 경우는 어떤가?

> 요즘 핫하게 클릭되는 https://yceffort.kr/2020/11/avoid-default-export 이글도 살펴보세여 😘

```javascript
export { data }
export default data

setTimeout(() => {
  data = 10
}, 500)
```

```javascript
import { data, default as data2 } from './module.js'
import data3 from './module.js'

setTimeout(() => {
  console.log(data) // 10
  console.log(data2) // 5
  console.log(data3) // 5
}, 1000)
```

그렇다, default는 모두 값이 변하든 말든 상관없이 초기의 값을 간직하고 있다.

`export default`는 , 혹시 이렇게 써본 적이 있는지는 모르겠지만, `default`로 바로 그냥 값을 내보내 버릴 수 있다.

```javascript
export default 'direct'
```

그러나 named exports, 이름으로 export를 하는 경우에는 불가능하다.

```javascript
// 이런 코드는 존재할 수 없다.ㄴㄴ
export {'direct' as direct}
```

`export default 'direct'`가 동작하게 하기 위해서, default export는 named export와는 다르게 동작한다. `export default`는 일종의 표현식처럼 동작하여 값을 바로 내보내거나, 연산을 통한 결과 값이 나가는 것이 가능하다. (`export default 'direct'` `export default 1+2`) 근데 여기서 또한 `export default data`도 가능하다. 두가지 모두를 가능하게 하기 위하여, `default`뒤에 오는 변수를 모두 값으로 처리를 하는 것이다. 따라서 export 하는 쪽에서 새로운 값으로 변하게 했다 하더라도, `export default`의 동작의 특성상 변한 값이 내보내지는게 아니라, 그 순간의 값이 나가게 된다.

정리하자면,

```javascript
// 특정 값을 참조하는 것 처럼 동작하여, 값이 바뀌면 서순에 따라서 그 바뀐 값을 들고 올 수도 있다.
import {data} from './module.js'
import {data as value} from './module.js'
import * as all from './module.js'
const module = await import('./module.js')
// 현재 값을 새로운 변수에 그대로 할당해서, 참조측에서 값이 바뀌든 말든 최초의 값을 계속 간직한다.
let  { data } = await import('./module.js')

// 참조를 export
export {data}
export {data as data2}
// 현재 값 그 자체를 export
export default data
export default 'direct'
```

자 여기에 하나만 더 끼얹어보자. `export {}`는 값을 바로 내보낼 수는 없고 참조만 내보낼 수 있다.

```javascript
let data = 5

export {data, data as default}
setTimeout(() => {
  data = 10
}, 500)}
```

```javascript
import { data, default as data2 } from './module.js'
import data3 from './module.js'

setTimeout(() => {
  console.log(data) // 10
  console.log(data2) // 10
  console.log(data3) // 10
}, 1000)
```

뭐야 이건 또, 값이 다 바꼈다. `export default data`와는 다르게, `export {data as default}`는 값이 아닌 참조를 내보낸 것을 알 수 있다. `as default`는 named export 와 같은 문법이므로, 참조를 내보낸 것을 알 수 있다.

그래서 또또 정리하자면,

```javascript
// 특정 값을 참조하는 것 처럼 동작하여, 값이 바뀌면 서순에 따라서 그 바뀐 값을 들고 올 수도 있다.
import {data} from './module.js'
import {data as value} from './module.js'
import * as all from './module.js'
const module = await import('./module.js')
// 현재 값을 새로운 변수에 그대로 할당해서, 참조측에서 값이 바뀌든 말든 최초의 값을 계속 간직한다.
let  { data } = await import('./module.js')

// 참조를 export
export {data}
export {data as data2}
export {data as default}
// 현재 값 그 자체를 export
export default data
export default 'direct'
```

함수는 어떨까?

```javascript
export default function getData() {}

setTimeout(() => {
  getData = '사실 변수 였습니다. 짜잔'
}, 500)
```

```javascript
import getData from './module.js'

setTimeout(() => {
  console.log(getData) // 사실 변수 였습니다. 짜잔
}, 1000)
```

.......?

```javascript
function getData() {}

export default getData

setTimeout(() => {
  getData = '사실 변수 였습니다. 짜잔'
}, 500)
```

```javascript
import getData from './module.js'

setTimeout(() => {
  console.log(getData) // [Function: getData]
}, 1000)
```

.....

`export default function`와 `export default class`는 조금 특별하다.

```javascript
function someFunction() {}
class SomeClass {}

console.log(typeof someFunction) // "function"
console.log(typeof SomeClass) // "function"
```

```javascript
;(function someFunction() {})
;(class SomeClass {})

console.log(typeof someFunction) // "undefined"
console.log(typeof SomeClass) // "undefined"
```

`function`과 `class` 문은 스코프/블록내에서는 identifier, 식별자를 만드는 반면, `function` `class` 표현식은 그렇지 않다.

따라서,

```javascript
export default function someFunction() {}
console.log(typeof someFunction) // "function"
```

만약, `export default function`이 값으로 내보내졌다면, 즉 기존의 `export default`와 동일하게 동작하여 표현식으로 동작했다면, `function`이 아닌 `undefined`로 찍혔을 것이다.

그래서 또또또또 요약을 하자면,

```javascript
// 특정 값을 참조하는 것 처럼 동작하여, 값이 바뀌면 서순에 따라서 그 바뀐 값을 들고 올 수도 있다.
import {data} from './module.js'
import {data as value} from './module.js'
import * as all from './module.js'
const module = await import('./module.js')
// 현재 값을 새로운 변수에 그대로 할당해서, 참조측에서 값이 바뀌든 말든 최초의 값을 계속 간직한다.
let  { data } = await import('./module.js')

// 참조를 export
export {data}
export {data as data2}
export {data as default}
export default function getData() {}
// 현재 값 그 자체를 export
export default data
export default 'direct'
```

여기서 한가지 명심해야할 것은, `export default 'direct'`는 값 그자체를 내보내는 반면, `export default function`은 참조를 내보낸다는 것이다.

> `export default = data` 와 같은게 차라리 더 나았을 지도 모른다..

호이스팅의 경우를 잠깐 생각해보자.

```javascript
work()

function work() {
  console.log("job's done")
}
```

이는 잘 알겠지만 동작한다. 함수 정의를 파일 위로 끌어올린다.

```javascript
// 둘다 안됨
assignedFunction()
new SomeClass()

const assignedFunction = function () {
  console.log('nope')
}
class SomeClass {}
```

`let` `const` `class` 식별자를 초기화 전에 쓰려고 하면, 에러가 발생한다.

```javascript
var foo = 'bar'

function test() {
  console.log(foo) // undefined
  var foo = 'hello'
}

test()
```

왜 undefined가 찍히는가? `var foo`는 함수 내에도 존재하고 있고, 함수 레벨에서 호이스팅이 있었고, `hello`로 할당되기 전에 호출되었기 때문에 값이 없는 것이다.

자바스크립트 내부에서는 아래와 같이 순환참조가 허용된다. 물론, 권장하지는 않는다.

```javascript
import { hi } from './module.js'

hi()

export function hello() {
  console.log('hello')
}
```

```javascript
import { hello } from './index.js'

hello()

export function hi() {
  console.log('hi')
}
```

"hello", 그 다음에 "hi" 가 나온다.이는 호이스팅 때문에 가능한 것이다. 호이스팅은 함수 정의를 호출 보다 위로 끌어올리기 때문이다.

그러나... 아래의 경우에는 안된다.

```javascript
import { hi } from './module.js'

hi()

export const hello = () => console.log('hello')
```

```javascript
import { hello } from './index.js'

hello()

export const hi = () => console.log('hi')
```

```
hello()
^

ReferenceError: Cannot access 'hello' before initialization
```

호이스팅이 일어나지 않아 `module.js`를 먼저 실행했고, `module.js`에서는 아직 있지도 않은 (호이스팅 되지도 않은) `hello`를 실행해서 에러가 발생하는 것이다.

하지만 아래 처럼 `export default`를 써보자.

```javascript
import foo from './module.js'

foo()

function hello() {
  console.log('hello')
}

export default hello
```

```javascript
import hello from './index.js'

hello()

function hi() {
  console.log('hi')
}

export default hi
```

이것도, 실패한다.

```
hello();
^

ReferenceError: Cannot access 'hello' before initialization
```

`module.js`에 있는 `hello`는 아직 초기화 되지않은 값이므로, 이를 호출하려다가 에러가 발생하게 된다.

그렇다, `export {hello as default}`로 바꿨다면 에러가 발생하지 않았을 것이다. 왜냐면 함수를 참조로 넘겨줬고, 그리고 그 순간 호이스팅이되었기 때문이다. `export default function hello()`도 마찬가지로 에러가 나지 않았을 것이다. 앞서 말했듯, `export default function`은 특별하게 처리한 케이스이기 때문이다.

## 결론!

```javascript
// 특정 값을 참조하는 것 처럼 동작하여, 값이 바뀌면 서순에 따라서 그 바뀐 값을 들고 올 수도 있다.
import {data} from './module.js'
import {data as value} from './module.js'
import * as all from './module.js'
const module = await import('./module.js')
// 현재 값을 새로운 변수에 그대로 할당해서, 참조측에서 값이 바뀌든 말든 최초의 값을 계속 간직한다.
let  { data } = await import('./module.js')

// 참조를 export
export {data}
export {data as data2}
export {data as default}
export default function getData() {}
// 현재 값 그 자체를 export
export default data
export default 'direct'
```

그리고, 위를 잘 참조하여 호이스팅이 발생할지 예측해보자.

> - https://jakearchibald.com/2021/export-default-thing-vs-thing-as-default/
> - https://developer.mozilla.org/ko/docs/orphaned/Web/JavaScript/Reference/Statements/export
> - https://nodejs.org/api/esm.html


자바스크립트는 멋져 짜릿해 늘 새로워

Export에 숨겨져 있는 심오함

nodejs 프로세스가 종료되는 상황으로는 여러가지가 있다. 에러가 발생하는 케이스와 같이 사전에 예방할 수 있는 경우가 있고, 혹은 메모리 부족과 시스템 오류와 같은 예방할 수 없는 것이 있다. 이 Process Global은 Event Emitter 인스턴스이며, graceful exit가 실행되면, 종료 이벤트를 발생 (emit) 한다. 그러면 애플리케이션 코드가 이 이 벤트를 수신하여 마지막 순간에 동기로 일어나는 정리 작업을 할 수 있다.

다음은 프로세스 종료를 의도적으로 발생시킬 수 있는 몇가지 방법이다.

| Operation                   | 예시                         |
| --------------------------- | ---------------------------- |
| 수동 프로세스 종료          | `process.exit(1)`            |
| Uncaught exception          | `throw new Error()`          |
| Unhandled promise rejection | `Promise.reject()`           |
| error event 무시            | `EventEmitter#emit('error')` |
| Unhandled Signals           | `$ kill <PROCESS_ID>`        |

이러한 오류 중 대부분은 `uncaught errors` `unhandled rejects`와 같이 실수로 발생되는 경우도 있지만, 이 들 중 일부는 프로세스를 직접 종료하기 위해 만들어 진 것이다.

## Process Exit

`process.exit(code)`는 프로세스를 종료하기 위한 가장 간단한 도구다. 프로세스의 수명이 다하여 종료시켜도 되는 경우에 스크립트를 작성할 때 매우 유용하다. 이 코드는 선택사항이며, 기본값은 0 이고 0에서 255까지 선택 가능하다. 0은 성공적인 프로세스 실행을 나타내는 반면, 0이 아닌 숫자는 사고가 발생했다는 것을 나타낸다. 이러한 값은 다양한 외부 툴에서 사용된다. 예를 들어, 테스트를 실행 할 때, 0이 아니면 테스트가 실패한 것이다.

`process.exit`가 직접 실행되면, 콘솔에는 암묵적으로 텍스트가 출력되지 않는다. 오류를 알리기 위해 이 메서드를 호출하는 경우, 사용자가 직접 오류를 찍어야 한다.

```bash
$ node -e "process.exit(42)"
$ echo $?
```

이 경우, shell이 종료를 나타내긴 했지만, nodejs 애플리케이션에서는 이 메시지가 출력되지 않았다. 이렇게 되면 사용자는 무슨 일이 일어났는지를 알지 못한다. 따라서 아래와 같이 종료시키는 것이 좋다.

```javascript
function checkConfig(config) {
  if (!config.host) {
    console.error("Configuration is missing 'host' parameter!")
    process.exit(1)
  }
}
```

사용자는 이 경우 명확하게 이해할 수 있다. 콘솔에 에러가 찍히고, 사용자는 이 상황에 대해 이해하고 해걸할 수 있다.

`process.exit()`는 매우 강력한 도구다. 하지만 재사용 가능한 라이브러리에 이 코드를 사용해서는 안된다.라이브러리에서 오류가 발생하면 애플리케이션이 오류를 어떻게 할지 결정할 수 있도록 오류를 생성해야 한다.

## Exceptions, Rejections, 그리고 Emitted Error

`process.exit()`는 시작/설정단계에서 사용할 수 있는 강력한 도구인반면, 실행 단계에서는 다른 툴을 사용해야한다. 예를 들어, 애플리케이션이 http 요청을 처리할 때 발생하는 오류는 프로세스를 종료하지 않고 오류 응답만 반환해야 한다. 오류가 발생한 위치에 대한 정보를 노출하는 것도 필요하다. 따라서 여기서 던져진 오류 객체가 유용하다.

`Error` 클래스의 인스턴스에는 스택 추적 및 메시지 문자열과 같이 오류의 원인을 파악하는데 유용한 메타데이터가 포함되어 있다. `Error` 클래스를 기반으로 사용자가 고유의 애플리케이션 `Error` 클래스를 만들어서 확장해서 사용하는 것이 일반적이다. `Error`를 인스턴스화하는 것 자체로는 부수효과가 없다. (=별일이 일어나지 않는다.) 오류가 발생하기 위해서는, 이 `Error` 클래스를 던져야 한다.

에러는 `throw` 키워드를 사용해서 던지거나, 특정 논리적인 오류가 발행할때 나타난다. 이러한 상황이 나타나면 현재 스택은 `unwinds`가 된다. 이 뜻은 각 함수가 `try...catch` 가 감싸는 문구를 만날 때까지 종료됨을 의미한다. 만약 `try...catch`를 만나지 못한다면, 이 는 uncaught된 에러로 간주한다.

`throw` 키워드를 사용하여 `throw new Error('hi')`와 같이 에러를 던지는 것은, 기술적으로 무엇이든 던질 수 있다. 무엇이든 던져지게 되면 이는 예외로 간주된다. 이렇게 던져지는 에러 인스턴스는 이 인스턴스를 기반으로 에러의 속성을 예상할 수 있으므로, 에러 인스턴스를 생성하는 것이 중요하다.

Node.js 라이브러리 내부에서 널리 사용되는 또다른 패턴은, 릴리즈 간에 일관성을 유지하기 위한 `.code` 값을 제공하는 것이다. 일례로 `ERR_INVALID_URI`가 있는데, 사람이 읽을 수 있는 `message`는 바뀔 수 있지만, `.code` 는 바뀌지 않는다.

안타깝게도, 에러를 구분하는 방법 중 또다른 하나는 `.message` 프로퍼티를 사용하는 것인데, 이는 위험하고 오류가 발생하기 쉽다. Node.js에서는 모든 라이브러리에서 오류를 완벽하게 구분할 수 있는 방법은 없다.

uncaught 에러가 스택에 던져지면, 콘솔에 찍히고 프로세스가 종료되며, 종료 상태값은 1이다. 이러한 예외의 예제를 살펴보자.

```bash
/tmp/foo.js:1
throw new TypeError('invalid foo');
^
Error: invalid foo
    at Object.<anonymous> (/tmp/foo.js:2:11)
    ... TRUNCATED ...
    at internal/main/run_main_module.js:17:47
```

`process` 글로벌은 Event Emitter로 `uncapturedException` 이벤트를 수신하여 uncaught 에러를 처리하는데 사용한다.

```javascript
const logger = require('./lib/logger.js')
process.on('uncaughtException', (error) => {
  logger.send('An uncaught exception has occured', error, () => {
    console.error(error)
    process.exit(1)
  })
})
```

Promise Rejection은 에러를 던지는 것과 유사하다. Promise에서 `reject()` 메서드가 호출되거나, 비동기 함수내에서 에러가 던져지는 경우 사용된다.

```javascript
Promise.reject(new Error('oh no'))
;(async () => {
  throw new Error('oh no')
})()
```

```
(node:52298) UnhandledPromiseRejectionWarning: Error: oh no
    at Object.<anonymous> (/tmp/reject.js:1:16)
    ... TRUNCATED ...
    at internal/main/run_main_module.js:17:47
(node:52298) UnhandledPromiseRejectionWarning: Unhandled promise
  rejection. This error originated either by throwing inside of an
  async function without a catch block, or by rejecting a promise
  which was not handled with .catch().
```

`uncaught exception`와는 다르게, 이러한 거부로 인해 node.js v14 에서는 크래쉬하지 않는다. 그러나, 그 이후 버전부터는 프로세스가 크래쉬된다. 또한 , 이 이벤트는 다음과 같이 캐치할 수 있다.

```javascript
process.on('unhandledRejection', (reason, promise) => {})
```

Event Emitter는 nodejs에서 흔한 패턴으로, 라이브러리와 애플리케이션 등에서 기본 클래스에서 확장한 많은 객체들이 존재한다.

Event Emitter가 `error` 이벤트를 발생시켰는데 여기에 아무런 리스너가 없다면, Emitter가 내보낸 인수를 던진다. 그렇게 되면 에러가 나서 프로세스가 종료된다.

```
events.js:306
    throw err; // Unhandled 'error' event
    ^
Error [ERR_UNHANDLED_ERROR]: Unhandled error. (undefined)
    at EventEmitter.emit (events.js:304:17)
    at Object.<anonymous> (/tmp/foo.js:1:40)
    ... TRUNCATED ...
    at internal/main/run_main_module.js:17:47 {
  code: 'ERR_UNHANDLED_ERROR',
  context: undefined
}
```

작업하는 Event Emitter 인스턴스에서 에러 이벤트를 수신하여, 애플리케이션이 멈추지 않고 이벤트를 정상적으로 처리할 수 있도록 해야 한다.

## Signal

시그널은 운영체제에서 하나의 프로그램에서 다른 프로그램으로 작은 숫자 메시지를 보내기 위해 제공하는 메커니즘이다. 이러한 숫자는 상수 문자열로 참조되는 경우가 많다. 예를 들어, 시그널 `SIGKILL`은 숫자 9의 시그널을 나타낸다.

운영 체제에 따라 서로다른 시그널이 정의될 수 있지만, 아래 목록은 일반적으로 범용이다.

| 이름    | 숫자 | handleable | Node.js 동작 | 목적                                |
| ------- | ---- | ---------- | ------------ | ----------------------------------- |
| SIGUP   | 1    | YES        | 종료         | 부모 터미널이 종료된 경우           |
| SIGINT  | 2    | YES        | 종료         | `Ctrl + C`로 터미널에 간섭하는 경우 |
| SIGQUIT | 3    | YES        | 종료         | `Ctrl + D`로 터미널을 끝내려는 경우 |
| SIGKILL | 9    | NO         | 종료         | 프로세스가 강제로 죽는 경우         |
| SIGUSR1 | 10   | YES        | 디버거 시작  | 사용자 정의 시그널 1                |
| SIGUSR2 | 12   | YES        | 종료         | 사용자 정의 시그널 2                |
| SIGUSR1 | 10   | YES        | 종료         | 정상종료                            |
| SIGUSR1 | 19   | NO         | 종료         | 프로세스가 강제로 멈추는 경우       |

프로그램에서 이러한 시그널 처리를 구현할 수 있도록 한 경우, Handleable이 YES 다. NO로 표시되어 있는 경우 처리할 수 없다. Node.js 동작은 신호가 수신되었을 때 Node.js 프로그램의 기본작업을 나타낸다. 마지막 열은, 일반적으로 어떻게 사용되는지 알려준다.

Node.js에서 이러한 시그널을 수신하기 위해서는, 아래처럼 `process`객체에 이벤트 리스너를 달면 된다.

```javascript
#!/usr/bin/env node
console.log(`Process ID: ${process.pid}`)
process.on('SIGHUP', () => console.log('Received: SIGHUP'))
process.on('SIGINT', () => console.log('Received: SIGINT'))
setTimeout(() => {}, 5 * 60 * 1000) // keep process alive
```

이 프로그램을 터미널에서 실행하고, `Ctrl+C`를 해보면, 프로세스가 죽지 않는다. 그 대신, `SIGINT`시그널을 받는다. 다른 터미널 창으로 가서, 프로세스 ID 값을 기준으로

```bash
$ kill -s SIGHUP <PROCESS_ID>
```

를 실행하면, 이는 한 프로그램이 다른 프로그램으로 신호를 보낼 수 있다는 것을 알 수 있다. 이전 터미널에서 실행중인 node.js 프로그램이 SIGHUP 신호를 수신하여 인쇄한다.

눈치챘을 수도 있지만, Node.js 는 다른 프로그램에도 명령을 전송할 수 있다.

```bash
$ node -e "process.kill(<PROCESS_ID>, 'SIGHUP')"
```

이는 첫번째 프로그램에 `SIGHUP`를 표시하게 한다. 만약, 해당 프로세스를 종료 시키고 싶다면 아래 명령어를 통해서 `SIGKILL` 시그널을 보내면 된다.

```bash
$ kill -9 <PROCESS_ID>
```

이 시점에서, 애플리케이션은 종료된다.

이러한 시그널은 정상 종료 처리 이벤트를 처리하기 위해 Node.js 애플리케이션에서 많이 사용된다. 예를 들어 쿠버네틱스의 pod가 종료되면 애플리케이션에 `SIGTERM` 신호를 보낸다음, 30초 타이머를 시작한다. 그러면 애플리케이션이 30초 내에 정상적으로 종료되면서 연결을 닫고, 데이터를 저장할 수 있다. 타이머 이후에도 프로세스가 활성화 되어있으면 쿠버네틱스가 `SIGKILL`을 보낸다.

https://thomashunter.name/posts/2021-03-08-the-death-of-a-nodejs-process


Nodejs 프로세스를 종료시키는 방법

매번 느끼는 거지만 자바스크립트 생태계는 진짜 쉴새 없이 변한다. 하루에도 수십 수백가지의 패키지가 만들어지고, 또 잘나가는 프로젝트는 오늘도 버전업과 기능 추가에 여념이 없다.

그런 와중에 내 눈에 들어온 것이 npm workspace와 esbuild다. npm workspace는 과연 lerna의 아성을 넘을 만큼 잘만들어졌을까? esbuild는 또 걔네들이 말하는 것처럼 엄청 빠를까?

## 예제 레파지토리

https://github.com/yceffort/workspaces-esbuild-example

## npm workspace

npm v7 이 정식으로 나오면서 모노레포를 지원하게 되었다. 원래 monorepo는 lerna와 yarn이 꽉잡고 있던 영역이었는데, 이번에 npm이 등장하게 되면서 npm cli로도 workspace를 활용하면 모노레포를 구축할 수 있게 되었다.

https://docs.npmjs.com/cli/v7/using-npm/workspaces

이 기능을 활용하면, 로컬 파일시스템에서 연결된 패키지를 훨씬 더 효율적으로 관리할 수 있게 해준다. 기존에 원래 있던 명령어인 `npm install`을 활용하면 자동으로 패키지를 link 해주고, 서로 다른 패키지 레벨에서 `npm link`할 필요 없이 알아서 현재 폴더의 `node_modules`를 가지고 연결해준다.

npm workspace를 어떻게 구축하는지 먼저 살펴보자.

```json
{
  "name": "@yceffort/monorepo",
  "version": "0.0.1",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build:all": "npm run build --workspaces",
    "deploy:all": "npm run deploy --workspaces",
    "lint": "eslint '**/*.{js,ts,tsx}'",
    "lint:fix": "npm run lint -- --fix",
    "prettier": "prettier '**/*.{json,yaml,md}' --check",
    "prettier:fix": "prettier '**/*.{json,yaml,md}' --write"
  },
  "author": "yceffort",
  "license": "ISC",
  "devDependencies": {
    "esbuild": "^0.12.12",
    "esbuild-node-externals": "^1.3.0",
    "eslint-config-yceffort": "0.0.5",
    "typescript": "^4.3.4"
  },
  "workspaces": ["./packages/*"]
}
```

먼저 프로젝트 루트 디렉토리에서 `workspaces`를 정의해줘야 한다. 위 예제에서는, `packages` 디렉토리 이하에 있는 프로젝트를 각각 모노레포의 모듈로 가져가기 위해 설정해두었다.

그리고 모노레포로 가져갈 레파지토리에 package.json을 설정해 둬야 한다. 이는 일반적인 패키지 설정과 별 차이가 없다.

여기서 `npm install`을 해보자.

> 한가지 중요한 것은 (당연한 이야기지만) npm v7 이어야 한다는 것이다. 이 실험을 위해서 무작정 npm v7을 설치하는 것은 권장하지 않는다. v7의 또한가지 변경점은 package-lock.json의 관리방식이 변경되었다는 것이다. (lock-version이 2로 올라갔다) 그래서 npm v7 을 버전업 한 후에 다른 프로젝트에서 npm i 를 날리면 package-lock.json에 무지막지한 diff 가 생성될 것이다. 이를 방지하기 위해 `npx npm@7` 를 사용하도록 하자. 뭐, 다른 프로젝트도 lockversion v2를 가져가도 괜찮다면 상관없다.

![npm-workspace](./images/npm-workspace-1.png)

여러개의 `package.json`이 있지만, `node_modules`는 루트에만 생성된 것을 볼 수 있다. 하위 패키지들의 참조는 모두 이 루트의 `node_modules`로 이어져 있다. (앞서 장황하게 설명한 그것)

이러한 패키지 설정을 매번 수동으로 할 필요는 없다.

```bash
npm init -w ./packages/some-package
```

이렇게 하면 알아서 하위 패키지를 만들어둔다. 단, 루트에 있는 `package.json`에 `workspaces` 값이 새롭게 추가된 패키지도 가르키고 있는지 확인해야 한다. 난 그게 귀찮아서 `*`로 처리했다.

만약 워크 스페이스에 의존성을 설치하고 싶다면,

```bash
npm install react -w some-package
```

와 같은 방식으로 하면 된다. 물론, `package.json`에 직접 방문해서 루트에서 `npm install`을 설치해도 된다.

## esbuild

자바스크립트는 느리다. 애초에 이렇게까지 쓰기 위해서 설계된 언어가 아니기 때문이다. 애초에 웹페이지에 있는 폼이나, 간단한 연산 정도만 처리할 용도로만 만들어졌기 때문이다. (싱글 스레드) 따라서 번들러가 느린 것도 어느정도 어쩔 수 없는 문제(?) 로 다들 받아드리고 있었다. 그런데, 아예 번들러를 저수준의 다른언어인 GO로 만들어버려서 이 속도문제를 해결한 것이 바로 esbuild다.

https://esbuild.github.io/

이 esbuild로 모노레포를 한번 만들어보려고 한다.

https://esbuild.github.io/getting-started/#your-first-bundle

```javascript
// esbuild
const esbuild = require('esbuild')
// 빌드시에 자동으로 node_modules를 제외 해준다.
// https://github.com/pradel/esbuild-node-externals
const { nodeExternalsPlugin } = require('esbuild-node-externals')

esbuild
  .build({
    entryPoints: ['./src/index.ts'],
    outfile: 'dist/index.js',
    bundle: true,
    minify: true,
    platform: 'browser',
    format: 'esm',
    sourcemap: true,
    target: 'es6',
    plugins: [nodeExternalsPlugin()],
  })
  .catch(() => process.exit(1))
```

처음 설정을 하고 느꼈던 첫인상은, webpack이나 rollup 처럼 json 설정이 불가능하다는 것이다. `.babelrc`와 같은 [cosmicconfig](https://github.com/davidtheclark/cosmiconfig)로 설정파일을 만드는 것이 불가능하다.

본격적으로 설정파일을 하나씩 파헤쳐보자.

- [entryPoints](https://esbuild.github.io/api/#entry-points): 번들링 알고리즘이 들어가게 되는 애플리케이션의 entry 포인트다. 보시다시피 ts가 자동지원 되기 때문에 (다 지원되는 건 아니다.) 타입스크립트 파일을 넣어도 무방하다.
- [outfile](https://esbuild.github.io/api/#outfile): 번들의 결과물이다. `entryPoints`와는 다르게, 딱 하나의 파일만 (문자열만) 가능한 것을 볼 수 있다. 단하나의 번들된, 그리고 minified된 파일이 나오게 된다.
- [bundle](https://esbuild.github.io/api/#bundle): 번들링 여부
- [minify](https://esbuild.github.io/api/#minify): minification (자바스크립트 파일 축소) 여부
- [platform](https://esbuild.github.io/api/#platform): 번들링된 파일이 어느 환경에서 실행될지를 결정하게 된다.
- [format](https://esbuild.github.io/api/#format): 생성된 파일의 형태를 나타낸다. `iife`, `cjs` `esm`이 가능하다.
- [sourcemap](https://esbuild.github.io/api/#sourcemap): 디버깅을 용이하게 해주는 소스맵 제공 여부
- [target](https://esbuild.github.io/api/#target): 어떤 플랫폼의 버전에서 사용할 수 있을지 명시한다. 가능한 옵션은 https://esbuild.github.io/content-types/#javascript 여기에 있다.

위 설정대로 esbuild를 실행해보자.

**sum.ts**

```typescript
export default function sum(...args: number[]) {
  return args.reduce((prev, acc) => acc + prev, 0)
}
```

**formatNumber.ts**

```typescript
export default function formatNumberWithComma(value: string | number): string {
  if (typeof value === 'string' && isNaN(+value)) {
    return value
  }

  let formattedNumber = `${value}`

  const reg = /(^[+-]?\d+)(\d{3})/

  while (reg.test(formattedNumber)) {
    formattedNumber = formattedNumber.replace(reg, '$1,$2')
  }

  return formattedNumber
}
```

**index.ts**

```typescript
export { default as sum } from './sum'
export { default as formatNumberWithComma } from './formatNumber'
```

**결과**

(minified된 파일을 보기 쉽게 하기 위해 unminifed함.)

```javascript
function m(...r) {
  return r.reduce((t, e) => e + t, 0)
}

function o(r) {
  if (typeof r == 'string' && isNaN(+r)) return r
  let t = `${r}`,
    e = /(^[+-]?\d+)(\d{3})/
  for (; e.test(t); ) t = t.replace(e, '$1,$2')
  return t
}
export { o as formatNumberWithComma, m as sum }
//# sourceMappingURL=index.js.map
```

## 삽질하면서 깨달은 것들, 그리고 감상

- target을 ES5로 할수 없다. 이는 공식 문서 https://esbuild.github.io/content-types/ 에도 나와있고, 찾아보니 제작자도 지원할 생각이 없는 것 같다. https://github.com/evanw/esbuild/issues/182#issuecomment-646297130 따라서 별도로 transpile 후에, 다시 esbuild를 해줘야 한다.
- 타입스크립트를 지원하지만, d.ts를 emit 해주지 않는다. 이를 위해서는 별도로 `tsc`를 실행해서 타입을 만들어야 한다. 그래서 빌드시 별도로 `tsc`를 실행했다.

```json
{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "baseUrl": ".",
    "rootDir": "src",
    "outDir": "./dist",
    "declarationDir": "./dist",
    // 이 아래 두개가 중요
    "emitDeclarationOnly": true,
    "declaration": true,
    "types": ["jest", "node"]
  },
  "include": ["./src/**/*.ts"],
  "exclude": ["node_modules", "dist"]
}
```

- css module 번들링이 아직 완벽하지는 않은 것 같다. https://github.com/evanw/esbuild/issues/20 현재 제작자가 최선을 다해서(?) 작업중이라고 한다.
- 그 밖에도 아직 작업중인 것들이 많다. 0.x 버전인데에는 이유가 있었다.
- `npx npm@7`을 매번 해주는 것이 너무 귀찮았다 (...) 가끔 이 사실을 까먹고 workspace를 쓰면 당연히 안된다. default로 7을 쓰고 싶지만, 다른 프로젝트 때문에 쓰지 못해서 아쉬웠다. 물론, `nvm`을 써서 node@16을 쓰고, 여기의 기본 npm 버전에 의존하는 방법 (7.18.1)도 있었지만, 생각만큼 잘되지는 않았다.
- 방금 예제는 정말 간단한 패키지라서 속도를 체감할 수는 없었지만, 큰 패키지를 대상으로 실험해본 결과 정말로 크게 속도차이가 나긴 했다.
- `webpack` 환경에서도 사용할 수 있도록 [esbuild-loader](https://github.com/privatenumber/esbuild-loader)가 존재한다. 앞서 살펴본것처럼, minify, uglify도 esbuild가 해주기 때문에 terser를 대체할 수 있다.
  - 벤치마킹 : https://github.com/privatenumber/minification-benchmarks
- 제법 많은 플러그인들이 존재했다. https://github.com/esbuild/community-plugins
- 개발자가 혼자서 고군 분투 중이었다. 정말 멋있었다. (존경)
- esbuild로 SSR도 가능한 것처럼 보인다. https://github.com/egoist/maho 깊게 살펴보진 않았지만
  - 차라리 vite를 사용해보는 걸 추천하고 싶다. https://vitejs.dev/guide/ssr.html 물론 여기도 experimental이다.

웹팩은 이미 메이저버전이 5까지 나와있을 정도로 성숙한 프로젝트고, 또 많은 사람들이 널리 사용하고 있는 프로젝트다. (롤업과 parcel도 잊으면 안된다) 하지만 기존의 당연시 생각되는 것들을 깨는 새로운 것의 등장은 언제나 보는 사람으로 하여금 설레게 하는 것 같다. esbuild도 그런 프로젝트 중 하나로, 정식 버전 업데이트 까지 잘 만들어졌으면 좋겠다.

아, workspace도 npm 생태계에 모노레포를 잘 녹여낸 것 같아서 좋았다. lerna보다는 쓰기 편한 것 같은 느낌?하지만, npm@7에서 workspace말고 그외에는 글쎄... 🤔

https://blog.logrocket.com/whats-new-in-npm-v7/


Javascript 11

promise.then(f, f) vs promise.then(f).catch(f) 는 무엇이 다를까?

자바스크립트 의존성 관리자(npm, yarn, pnpm)에서 보다 더 의존성 관리 잘하는 방법

Export에 숨겨져 있는 심오함

Nodejs 프로세스를 종료시키는 방법

npm workspace와 esbuild로 monorepo 구축해보기