## Table of Contents

출처는 [여기](https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/)

## 가변 튜플

튜플은 원소의 수와, 각 원소의 타입이 정확히 지정된 배열의 타입을 지정하고 싶을 때 사용하는 방법이다.

```typescript
const hello: [string, number] = ['yc', 33]
```

먼저 tuple 타입 신택스에 있는 spread 연산자 `...`가 제네릭하게 될 수 있다. (외부에서 타입을 지정할 수 있다.) 블로그에서 나온 예시로는, `tail`함수를 예로 들고 있다.

```typescript
// 이 ... 이 3.x 버전 이하에서는 에러가 났지만, 4.0 부터는 쓸 수 있게 되었다.
function tail<T extends any[]>(arr: readonly [any, ...T]) {
 const [_ignored, ...rest] = arr
 return rest
}

const myTuple = [1, 2, 3, 4] as const
const myArray = ['hello', 'world']

// type [2, 3, 4]
const r1 = tail(myTuple)

// type [2, 3, 4, ...string[]]
const r2 = tail([...myTuple, ...myArray] as const)
```

[예제코드](https://www.typescriptlang.org/play?ts=4.0.2#code/GYVwdgxgLglg9mABFAhjANgHgCqIKYAeUeYAJgM6IpgCeA2gLoB8AFCgE7sBci7eKpBOhqI61GgBpEAOlnYGASkQBvAFCINiCAnJRRAfRgBzMHD6kps6X10NEAXiqcA3Os18oIdkhtRXAX1VVbTBdRABbGmwQAAd0PAdRAEYpACYpAGYpABY7FEoQ3VdCvUiAQU4UEUc6ACIACzx0dDhaqVqAdzN0UlqGV1UAekHkGhiEunTELMRc4J09diTE1AwWSOi4vAUB4dHx0SmZ7MtZXXYYMCNGBnnQxdSVtHQWOisN2PjT6XLKmjyCgsdkA)

또한 tuple 내부에서 전개 연산자를 어디서든 쓸 수 있다.

```typescript
type Strings = [string, string]
type Numbers = [number, number]

// [string, string, number, number, boolean]
type StrStrNumNumBool = [...Strings, ...Numbers, boolean]
```

아마도 함수 합성을 하는데 있어서 중요한 역할을 할 것으로 보인다. 블로그에 예제에서 보여준 것처럼, 자바스크립트의 `bind`함수에 타입체크를 할 때도 많이 이용될 것으로 보인다.

[다양한 예제들](https://github.com/microsoft/TypeScript/pull/39094)

```typescript
// Variadic tuple elements

type Foo<T extends unknown[]> = [string, ...T, number]

type T1 = Foo<[boolean]> // [string, boolean, number]
type T2 = Foo<[number, number]> // [string, number, number, number]
type T3 = Foo<[]> // [string, number]

// Strongly typed tuple concatenation
function concat<T extends unknown[], U extends unknown[]>(
 t: [...T],
 u: [...U],
): [...T, ...U] {
 return [...t, ...u]
}

const ns = [0, 1, 2, 3] // number[]

const t1 = concat([1, 2], ['hello']) // [number, number, string]
const t2 = concat([true], t1) // [boolean, number, number, string]
const t3 = concat([true], ns) // [boolean, ...number[]]

// Inferring parts of tuple types
declare function foo<T extends string[]>(...args: [...T, () => void]): T

foo(() => {}) // []
foo('hello', 'world', () => {}) // ["hello", "world"]
foo('hello', 42, () => {}) // Error, number not assignable to string

// Inferring to a composite tuple type
function curry<T extends unknown[], U extends unknown[], R>(
 f: (...args: [...T, ...U]) => R,
 ...a: T
) {
 return (...b: U) => f(...a, ...b)
}

const fn1 = (a: number, b: string, c: boolean, d: string[]) => 0

const c0 = curry(fn1) // (a: number, b: string, c: boolean, d: string[]) => number
const c1 = curry(fn1, 1) // (b: string, c: boolean, d: string[]) => number
const c2 = curry(fn1, 1, 'abc') // (c: boolean, d: string[]) => number
const c3 = curry(fn1, 1, 'abc', true) // (d: string[]) => number
const c4 = curry(fn1, 1, 'abc', true, ['x', 'y']) // () => number
```

## 튜플 요소에 이름 지정하기

튜플에 이름을 지정할 수 있다.

```typescript
type Range = [start: number, end: number]
type Foo = [first: number, second?: string, ...rest: any[]]
```

대신 하나라도 이름을 지정하면, 그 뒤에도 주르륵 이름을 지정해야 한다.

```typescript
type Bar = [first: string, number]
// error! Tuple members must all have names or all not have names.
```

## 생성자에서 클래스 프로퍼티 추론

`noImplicitAny` 속성이 켜져 있다면, 아래와 같은 추론이 가능해진다.

```typescript
class Square {
 // Previously: implicit any!
 // Now: inferred to `number`!
 area
 sideLength

 constructor(sideLength: number) {
 this.sideLength = sideLength
 this.area = sideLength ** 2
 }
}
```

그리고 위의 정보만으로는 추론할 수 없는 경우에는 `undefined`에러가 난다.

```typescript
class Square {
 sideLength

 constructor(sideLength: number) {
 if (Math.random()) {
 this.sideLength = sideLength
 }
 }

 get area() {
 return this.sideLength ** 2
 //
 // error! Object is possibly 'undefined'.
 }
}
```

사실 저렇게 하는 것보다, 명확하게 타입을 선언하고 초기화 해주는 것이 낫다.

## 간략 할당 연산자

자바스크립트에는 아래와 같이 간략하게 할당하는 연산자가 존재한다.

```javascript
// Addition
// a = a + b
a += b

// Subtraction
// a = a - b
a -= b

// Multiplication
// a = a * b
a *= b

// Division
// a = a / b
a /= b

// Exponentiation
// a = a ** b
a **= b

// Left Bit Shift
// a = a << b
a <<= b
```

새로운 ECMAScript의 표준에 맞춰, 타입스크립트에도 `&&=` `||=` `??=` 도 지원하게 된다.

```typescript
a = a && b
a = a || b
a = a ?? b
```

```typescript
const obj = {
 get prop() {
 console.log('getter has run')

 // Replace me!
 return Math.random() < 0.5
 },
 set prop(_val: boolean) {
 console.log('setter has run')
 },
}

function foo() {
 console.log('right side evaluated')
 return true
}

console.log('This one always runs the setter')
obj.prop = obj.prop || foo()

console.log('This one *sometimes* runs the setter')
obj.prop ||= foo()
```

## catch binding에 unknown사용

이전 까지는 에러 객체 타입이 `any`여서 아무럭ㅎ게나 사용할 수 있었다. 그러나 이제 `unknown`으로 간주되면서, 보다 안전하게 사용될 수 있다.

```typescript
try {
 // ...
} catch (e) {
 // error!
 // Property 'toUpperCase' does not exist on type 'unknown'.
 console.log(e.toUpperCase())

 if (typeof e === 'string') {
 // works!
 // We've narrowed 'e' down to the type 'string'.
 console.log(e.toUpperCase())
 }
}
```

그러나 이 기능은 개발자들에게 익숙해기 전까지 `--strict`모드를 켜놔야만 적용된다. 조만간 이를 위한 lint룰도 추가될 예정이다.

## Custom JSX Factory

JSX에서 [fragment](https://reactjs.org/docs/fragments.html)란 자식 엘리먼트 여러개를 반환하는 JSX 엘리먼트 타입을 의미한다. 과거 타입스크립트에 프래그먼트를 추가할 때는 별로 이에 대한 고민이 이뤄지지 않았지만, 현재는 많은 라이브러리들이 JSX를 사용하며 이에 관련된 API의 지원도 늘려가고 있다.

타입스크립트 4.0부터 `jsxFragmentFactory` 옵션을 사용해서 프래그먼트 팩토리를 커스터마이징 할 수 있다.

이렇게 하면 대신 React의 `Fragment`대신 `Fragment`를, `createElement`대신 `h`를 사용해야 한다.

`tsconfig.json`

```json
{
 "compilerOptions": {
 "target": "esnext",
 "module": "commonjs",
 "jsx": "react",
 "jsxFactory": "h",
 "jsxFragmentFactory": "Fragment"
 }
}
```

파일마다 JSX 팩토리를 다르게 사용하려면 `/** @jsxFrag */` 주석을 함께 사용해야 한다. 아래 예를 보자.

```typescript
// Note: these pragma comments need to be written
// with a JSDoc-style multiline syntax to take effect.
/** @jsx h */
/** @jsxFrag Fragment */

import { h, Fragment } from 'preact'

let stuff = (
 <>
 <div>Hello</div>
 </>
)
```

위 코드는 아래 처럼 빌드 된다.

```javascript
// Note: these pragma comments need to be written
// with a JSDoc-style multiline syntax to take effect.
/** @jsx h */
/** @jsxFrag Fragment */
import { h, Fragment } from 'preact'
let stuff = h(Fragment, null, h('div', null, 'Hello'))
```

## `--noEmitOnError` 빌드 시에 속도 향상

이전 버전 까지는 `----incremental`를 `--noEmitOnError`와 함께 사용하면 빌드가 매우 느렸다. 이는 `--noEmitOnError` 플래그를 사용하면, 이전 컴파일 결과에 대한 정보가 `.tsbuildinfo`파일에 캐싱되지 않았기 때문이다. 그리고 이를 해결해서 속도를 향상 시켰다.

## `--incremental`과 `--noEmit`

위와 동일

## VSCode 에디터 지원 개선

VSCode에서 원하는 타입스크립트 버전을 선택할 수 있도록 한다.

## 옵셔널 체이닝 지원

- 옵셔널 체이닝 지원
- null 병합연산자 지원

## `/** @deprecated */` 지원

JSDoc 에서 `/** @deprecated */`를 사용할 수 있도록 지원한다.

## 에디터 시작시 파셜 시맨틱 모드 지원

에디터 실행시간이 길다는 유저들의 불만이 많았다. 이를 해결 하기 위해 언어 지원 서비스 전체가 로딩되기 전에 바로 현재 파일에서 활용할 수 있는 부분 시맨틱 모드를 추가했다. 이는 에디터를 실행했을 때 현재 파일 만이라도 언어지원 서비스를 지원하는 것이다.

좌측 (구버전)과 우버전 (신버전) 을 비교하면 확연한 속도 차이를 느낄 수 있다.

<video loop="" autoplay="" muted="" style="width:100%;height:100%;" src="https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/partialModeFast.mp4" class="x-hidden-focus"></video>

## 더 똑똑해진 자동 임포트

타입스크립트로 작성된 라이브러리라 할지라도, 프로젝트에 한번도 로드 되지 않은 임포트 문이 자동으로 불러와지지 않는 문제가 있었다. 이는 자동 로드 기능이 해당 프로젝트에 한번이라도 로드된 패키지들을 대상으로만 동작하기 때문이다.

를 보완하기 위해, `package.json`의 `dependencies`와 `peerDependencies`를 처리하는 로직을 따로 추가했으며, 이 정보는 auto import 를 위해서만 사용된다.

## Breaking Changes

### `lib.d.ts` 수정

`lib.d.ts`가 수정되었다. 특히, DOM 타입 관련된 부분의 수정이 있었다. 그중 가장 유의깊게 봐야할 것은 [document.origin](https://developer.mozilla.org/en-US/docs/Web/API/Document/origin)대신에 [self.origin][https://developer.mozilla.org/en-us/docs/web/api/windoworworkerglobalscope/origin]를 사용하는 것이다.

### 프로퍼티, 게터, 세터 오버라이딩 금지

이전 버전까지는 `useDefineForClassFields`가 있어야만 오류로 처리했지만, 이제부터는 이 옵션이 없어도 에러가 발생한다. 이는 상속관계에서만 발생한다.

```typescript
class Base {
 get foo() {
 return 100
 }
 set foo() {
 // ...
 }
}

class Derived extends Base {
 foo = 10
 // ~~~
 // error!
 // 'foo' is defined as an accessor in class 'Base',
 // but is overridden here in 'Derived' as an instance property.
}
```

```typescript
class Base {
 prop = 10
}

class Derived extends Base {
 get prop() {
 // ~~~~
 // error!
 // 'prop' is defined as a property in class 'Base', but is overridden here in 'Derived' as an accessor.
 return 100
 }
}
```

### 옵셔널 항목만 delete 가능

`strictNullChecks`가 켜져 있는 상태에서 delete를 사용하면, 그 대상이 반드시 `any` `unknown` `never`이거나 옵셔널 항목이어야 한다. 그렇지 않으면 에러가 발생한다.

```typescript
interface Thing {
 prop: string
}

function f(x: Thing) {
 delete x.prop
 // ~~~~~~
 // error! The operand of a 'delete' operator must be optional.
}
```

### Node Factory 가 deprecated 되었다

AST(추상 구문 트리) 노드 생성을 위해, 팩토리 함수를 제공했지만, 이제는 새로운 API 형태로 노드 팩토리를 제공한다. 자세한 내용은 [여기](https://github.com/microsoft/TypeScript/pull/35282)를 참고

한 발 늦었지만 타입스크립트 4.0에서 추가된 기능을 알아보자

Typescript 4.0 릴리즈 노트 

몇 년 전 만 하더라도, C9이 지금의 프로게임단이 아닌 (...) 온라인 코드 에디터로 유명하던 때가 있었다.

![C9-IDE](https://miro.medium.com/max/700/1*q6Rn63AwFqlRx8N81PDIRw.png)

리눅스나 맥북을 기반으로 개발을 할 환경이 되지 않았던 시절, ASUS의 오래된 윈도우 노트북을 들고 다니면서 개발을 공부했을 때 주로 사용하던 것이 C9 이었다. 그 때는 기억으로는 무료에 특별하게 제한이 없어서 굉장히 유용하게 썼던 기억이 난다. (없었던 건 아니고 조심해서 썼던 거 같기도)

시간이 흘러 여전히 집에는 윈도우 컴밖에 없었고, 맥북은 무거워 오랫만에 C9을 찾았다. C9는 온대간대 없이 AWS에 인수되어 있었고, 이용료도 받고 있었다. (당연히 AWS Free Tier는 진작에 다썼고) 그래서 C9 대신 선택한 것이 VS Codespace (처음에는 VS Code Online인가 그랬다)였다. Azure에 내 개인정보를 팔아넘긴 덕분에 고맙게도 맥북에어에서 개발을 할 수 있게 많은 도움이 되었다. (흑흑)

그러던 어느날 VS Codespace가 github codespace로 이전될 예정이라 베타 신청을 받는다는 팝업이 떴다! 신청하고 한달만에! 드디어! 베타에 당첨이 되어! 쓰게 되었다!

![welcome to codespaces](./images/codespaces-beta.png)

지겨운! 도큐먼트는! 보지 않으련다! 대충 몇 가지로 요약해보자

- 이번 베타 기간에는 최대 두 개의 codespace를 개설할 수 있다. 따라서 쓰고 난뒤엔 지워야 한다.
- 당연하게도 VSCode와 연동해서 쓸 수 있다! [참고](https://docs.github.com/en/github/developing-online-with-codespaces/connecting-to-your-codespace-from-visual-studio-code)
- 프로젝트의 Codespace에 기본 설정을 적용해 둘 수 있다. [참고](https://docs.github.com/en/github/developing-online-with-codespaces/configuring-codespaces-for-your-project)
- 가격은 기존 VS Codespace의 미국 동부기준 가격과 동일하다. 성능별로 차이가 있으며, 아래를 참고하세용. (베타 기간엔 베이직만 존재하는 듯?)

가격은 나름 괜찮은 거 같다. 프리미엄이면 맥북 프로 최신형에 가까운 성능을 누릴 수 있다. 3시간 개발하면 1달러. 하루에 8시간, 20일 개발하면... 55달러다.

![price](./images/codespaces-price.png)

이제 Github에서 clone하는 영역에 이렇게 codespaces를 볼 수 있다.

![codespaces1](./images/codespaces1.png)

![codespaces2](./images/codespaces2.png)

![codespaces3](./images/codespaces3.png)

포트 포워딩도 제공해서, dev환경을 실행하면 실제로 들어가서 볼 수도 있다.

![codespaces4](./images/codespaces4.png)

![codespaces5](./images/codespaces5.png)

이제 맥북에어를 혹사시킬 필요도, 회사 맥북을 무겁게 들고 다니지 않아도 되는 시대가 왔다. 이제 코딩도 나 대신 로봇이 하는 시대만 오면 종말이 완성될 것 같다.

![doomsayer](https://img1.wikia.nocookie.net/__cb20131211232726/hearthstone/images/4/4c/Doomsayer.gif?width=200)

감사합니다 github 열심히 개발할게용


이게 당첨이 되네 (사실 아무나 되는 건 아니었겠지)

Github Code Spaces 베타 당첨 및 후기

몇 년 전 만 하더라도, C9이 지금의 프로게임단이 아닌 (...) 온라인 코드 에디터로 유명하던 때가 있었다.
<img src="https://miro.medium.com/max/700/1*q6Rn63AwFqlRx8N81PDIRw.png" alt="C9-IDE">
리눅스나 맥북을 기반으로 개발을 할 환경이 되지 않았던 시절, ASUS의 오래된 윈도우 노트북을 들고 다니면서 개발을 공부했을 때 주로 사용하던 것이 C9 이었다. 그 때는 기억으로는 무료에 특별하게 제한이 없어서 굉장히 유용하게 썼던 기억이 난다. (없었던 건 아니고 조심해서 썼던 거 같기도)
시간이 흘러 여전히 집에는 윈도우 컴밖에 없었고, 맥북은 무거워 오랫만에 C9을 찾았다. C9는 온대간대 없이 AWS에 인수되어 있었고, 이용료도 받고 있었다. (당연히 AWS Free Tier는 진작에 다썼고) 그래서 C9 대신 선택한 것이 VS Codespace (처음에는 VS Code Online인가 그랬다)였다. Azure에 내 개인정보를 팔아넘긴 덕분에 고맙게도 맥북에어에서 개발을 할 수 있게 많은 도움이 되었다. (흑흑)
그러던 어느날 VS Codespace가 github codespace로 이전될 예정이라 베타 신청을 받는다는 팝업이 떴다! 신청하고 한달만에! 드디어! 베타에 당첨이 되어! 쓰게 되었다!
<img src="./images/codespaces-beta.png" alt="welcome to codespaces">
지겨운! 도큐먼트는! 보지 않으련다! 대충 몇 가지로 요약해보자
<ul>
<li>이번 베타 기간에는 최대 두 개의 codespace를 개설할 수 있다. 따라서 쓰고 난뒤엔 지워야 한다.</li>
<li>당연하게도 VSCode와 연동해서 쓸 수 있다! <a href="https://docs.github.com/en/github/developing-online-with-codespaces/connecting-to-your-codespace-from-visual-studio-code">참고</a></li>
<li>프로젝트의 Codespace에 기본 설정을 적용해 둘 수 있다. <a href="https://docs.github.com/en/github/developing-online-with-codespaces/configuring-codespaces-for-your-project">참고</a></li>
<li>가격은 기존 VS Codespace의 미국 동부기준 가격과 동일하다. 성능별로 차이가 있으며, 아래를 참고하세용. (베타 기간엔 베이직만 존재하는 듯?)</li>
</ul>
가격은 나름 괜찮은 거 같다. 프리미엄이면 맥북 프로 최신형에 가까운 성능을 누릴 수 있다. 3시간 개발하면 1달러. 하루에 8시간, 20일 개발하면... 55달러다.
<img src="./images/codespaces-price.png" alt="price">
이제 Github에서 clone하는 영역에 이렇게 codespaces를 볼 수 있다.
<img src="./images/codespaces1.png" alt="codespaces1">
<img src="./images/codespaces2.png" alt="codespaces2">
<img src="./images/codespaces3.png" alt="codespaces3">
포트 포워딩도 제공해서, dev환경을 실행하면 실제로 들어가서 볼 수도 있다.
<img src="./images/codespaces4.png" alt="codespaces4">
<img src="./images/codespaces5.png" alt="codespaces5">
이제 맥북에어를 혹사시킬 필요도, 회사 맥북을 무겁게 들고 다니지 않아도 되는 시대가 왔다. 이제 코딩도 나 대신 로봇이 하는 시대만 오면 종말이 완성될 것 같다.
<img src="https://img1.wikia.nocookie.net/__cb20131211232726/hearthstone/images/4/4c/Doomsayer.gif?width=200" alt="doomsayer">
감사합니다 github 열심히 개발할게용

## 지극히 주관적인 책 리뷰

<iframe type="text/html" width="336" height="550" frameborder="0" allowfullscreen style="max-width:100%" src="https://read.amazon.com/kp/card?asin=B081Y3R657&preview=inline&linkCode=kpe&ref_=cm_sw_r_kb_dp_X.RyFb5WBPP20" ></iframe>

넷플릭스의 조직 문화하면 가장 먼저 떠오르는 것은, 아마도 gizmodo에서 쓴 기사일 것이다. [Working at Netflix Sounds Like Hell
](https://gizmodo.com/working-at-netflix-sounds-like-hell-1830020977)

> The profile’s sources described the “Netflix way” as a structure founded on brutal honesty, ritual humiliation, insider lingo, and constant fear. It’s a mix of elements that a lot of people in corporate culture might recognize but according to many employees, it’s been a chaotic process that is difficult to scale as the company carries out its plans of world domination.

이른바 `Keeper Test`를 통과하지 못한 직원들은 가차 없이 해고 한다는 것이고, 이러한 테스트로 인해 많은 직원들이 스트레스를 받는 다는 것이었다. 뭐, 미국이야 우리나라에 비해 쉬운 해고를 할 수 있으니 이런일이야 가능하겠지만서도, 넷플릭스가 성과에 대해 굉장히 깐깐한 문화를 가졌구나 라고 만 생각했다. 그런 회사의 CEO가 쓴 책이 바로 이 책이다. 이 책은 넷플릭스의 기업, 조직, 인사 문화를 담고 있다.

대충 요약하자면 다음과 같다.

> 업계 최고의 인재를 어떻게든 데려와서, 그들에게 최소한의 통제(휴가, 업무시간, 보고 등)와 최대의 자유를 주어라. 그리고 직원들에게 서로 솔직한 피드백을 (그러나 재수없지 않은) 주고받게 하며, 피드백에 적절히 대처하지 못하거나 솔직하지 못한 직원은 두둑한 보상금을 주고 쫓아내라
>
> 어떤 식이든 통제는 창의성을 저해하며, 최대한의 자유를 보장해야 한다. 그 자유 내에서 직원들은 무엇이 회사를 위해 최선인지 고민하게 될 것이다. 어떤식으로 결정했든지, 그 결정에 대한 맥락을 설명할 수 있으면 무슨 결정을 하든 상관 없다.

특히, 개발자의 경우에는 그저그런 개발자 10명 보다 슈퍼 탤런트를 가진 한명의 개발자를 훨씬 더 생산성이 뛰어나다고 이야기 하고 있다. 따라서 어떻게든, 업계 최고의 인재를 데려오는 것은 중요하며, 그러한 인재를 모셔오는 데 있어서 지원을 아끼지 말아야 한다고 강조한다.

그리고 이런 기업문화에 대해 동양권에서는 특히 힘들어 한다는 이야기도 포함되어 있었다. (도쿄의 예시) 우리나라 넷플릭스 직원들이 얼마나 있는지 모르겠지만, 아마 우리나라도 마찬가지 일 것이다. (해고까지 이런식으로 할 수 있을런지는 모르겠지만)

넷플릭스 CEO가 썼다는 것을 충분히 감안하더라도, 이들의 주장에는 어느정도 설득력이 있는 것 같다. 또한 실제 해고율도 다른 회사 대비 그렇게 높지 않다고 나와있었다.

마지막으로, 해고에 대한 걱정을 하고 있는 직원들에게 이런 말을 남겼다.

> 구멍난 배 쪽을 계속해서 보지마라. 노를 젓는 일에 방해가 될 뿐이다. 계속해서 나야가야 할 방향을 보고 노력해라. 그리고 내 위치에 대해, 자주 매니저에게 피드백을 요청하고 이를 수용하라.

그렇다면 과연 나에게 최대한의 자유가 주어졌을때, 최고의 성과를 낼 준비가 되어 있을까? 나는 그러한 일련의 과정마저 즐길 수 있을까?

규칙 없음: 넷플릭스, 지구상 가장 빠르고 유연한 기업의 비밀

[Book] No Rules Rules

<h2 id="지극히-주관적인-책-리뷰">지극히 주관적인 책 리뷰</h2>
<iframe type="text/html" width="336" height="550" frameborder="0" allowfullscreen style="max-width:100%" src="https://read.amazon.com/kp/card?asin=B081Y3R657&preview=inline&linkCode=kpe&ref_=cm_sw_r_kb_dp_X.RyFb5WBPP20" ></iframe>
넷플릭스의 조직 문화하면 가장 먼저 떠오르는 것은, 아마도 gizmodo에서 쓴 기사일 것이다. <a href="https://gizmodo.com/working-at-netflix-sounds-like-hell-1830020977">Working at Netflix Sounds Like Hell
</a>
<blockquote>
The profile’s sources described the “Netflix way” as a structure founded on brutal honesty, ritual humiliation, insider lingo, and constant fear. It’s a mix of elements that a lot of people in corporate culture might recognize but according to many employees, it’s been a chaotic process that is difficult to scale as the company carries out its plans of world domination.
</blockquote>
이른바 <code>Keeper Test</code>를 통과하지 못한 직원들은 가차 없이 해고 한다는 것이고, 이러한 테스트로 인해 많은 직원들이 스트레스를 받는 다는 것이었다. 뭐, 미국이야 우리나라에 비해 쉬운 해고를 할 수 있으니 이런일이야 가능하겠지만서도, 넷플릭스가 성과에 대해 굉장히 깐깐한 문화를 가졌구나 라고 만 생각했다. 그런 회사의 CEO가 쓴 책이 바로 이 책이다. 이 책은 넷플릭스의 기업, 조직, 인사 문화를 담고 있다.
대충 요약하자면 다음과 같다.
<blockquote>
업계 최고의 인재를 어떻게든 데려와서, 그들에게 최소한의 통제(휴가, 업무시간, 보고 등)와 최대의 자유를 주어라. 그리고 직원들에게 서로 솔직한 피드백을 (그러나 재수없지 않은) 주고받게 하며, 피드백에 적절히 대처하지 못하거나 솔직하지 못한 직원은 두둑한 보상금을 주고 쫓아내라
어떤 식이든 통제는 창의성을 저해하며, 최대한의 자유를 보장해야 한다. 그 자유 내에서 직원들은 무엇이 회사를 위해 최선인지 고민하게 될 것이다. 어떤식으로 결정했든지, 그 결정에 대한 맥락을 설명할 수 있으면 무슨 결정을 하든 상관 없다.
</blockquote>
특히, 개발자의 경우에는 그저그런 개발자 10명 보다 슈퍼 탤런트를 가진 한명의 개발자를 훨씬 더 생산성이 뛰어나다고 이야기 하고 있다. 따라서 어떻게든, 업계 최고의 인재를 데려오는 것은 중요하며, 그러한 인재를 모셔오는 데 있어서 지원을 아끼지 말아야 한다고 강조한다.
그리고 이런 기업문화에 대해 동양권에서는 특히 힘들어 한다는 이야기도 포함되어 있었다. (도쿄의 예시) 우리나라 넷플릭스 직원들이 얼마나 있는지 모르겠지만, 아마 우리나라도 마찬가지 일 것이다. (해고까지 이런식으로 할 수 있을런지는 모르겠지만)
넷플릭스 CEO가 썼다는 것을 충분히 감안하더라도, 이들의 주장에는 어느정도 설득력이 있는 것 같다. 또한 실제 해고율도 다른 회사 대비 그렇게 높지 않다고 나와있었다.
마지막으로, 해고에 대한 걱정을 하고 있는 직원들에게 이런 말을 남겼다.
<blockquote>
구멍난 배 쪽을 계속해서 보지마라. 노를 젓는 일에 방해가 될 뿐이다. 계속해서 나야가야 할 방향을 보고 노력해라. 그리고 내 위치에 대해, 자주 매니저에게 피드백을 요청하고 이를 수용하라.
</blockquote>
그렇다면 과연 나에게 최대한의 자유가 주어졌을때, 최고의 성과를 낼 준비가 되어 있을까? 나는 그러한 일련의 과정마저 즐길 수 있을까?

[이 글](https://indepth.dev/webpack-5-module-federation-a-game-changer-in-javascript-architecture/)을 위주로 번역한 글이며, 추가적으로 micro frontend에 대한 개념도 넣어두었습니다.

## Table of Contents

> Module Federation은 서버, 클라이언트 모두에서 자바스크립트 애플리케이션을 다른 번들/빌드로 부터 코드를 다이나믹하게 실행해준다.

이는 자바스크립트 번들러를 아폴로가 GraphQL에서 하는 것과 동일한 기능을 할 수 있게 해준다. (근데 내가 안써봐서 모름)

서로 독립된 애플리케이션 간에 코드를 공유할 수 있는 확장 가능한 솔루션은 여지껏 편리하지 않았으며, 확장은 불가능에 가까웠다. 코드를 공유하는 것도 번거롭고, 실제로 애플리케이션은 독립적이지도 않았으며, 종속성 또한 제한되어 있었다. 또한 실제 코드 형상이나 컴포넌트를 별도로 묶은 애플리케이션 간 공유는 불가능에 가까웠고, 비생산적이었으며, 수익성이 없었다.

Module Federation은 자바스크립트 애플리케이션이 다른 애플리케이션에서 동적으로 코드를 불러오고, 그 과정에서 종속성을 가질 수 있도록 허용한다. 만약 모듈을 사용하는 애플리케이션이 Module Federation에서 필요로 하는 종속성을 가지고 있지 않다면, 웹팩은 Module Entry Point에서 누락된 종속성을 다운로드 할 것이다.

코드는 가능하면 공유되지만, fallback은 각각의 케이스에 별도로 존재한다. Federated된 코드는 항상 종속성을 불러올수 있지만, 더 많은 페이로드를 다운로드 하기전에 사용하는 측의 종속성을 사용하려고 시도한다. 이말은, 획일적인 웹팩의 빌드 처럼 코드 중복과 의존성 공유가 적다는 것을 의미한다.

### 용어

- Module Federation: Apollo GraphQL federation 과 같은 개념을, 자바스크립트 모듈에 녹였다고 보면 된다. 브라우저와 node에서 사용가능하다.
- Host: 첫 페이지 로딩을 담당하는 웹팩 빌드 (`onLoadEvent`를 트리거하는)
- Remote: host에 의해 사용되는 다른 웹팩 빌드, host의 일부다.
- Bi-directional hosts: 번들 또는 웹팩 빌드가 호스트 또는 리모트로 작동할 수 있는 때. 런타임시에 각각 서로를 실행할 수 있다.

애플리케이션은 bi-directional host가 될 수 있다. 즉, 어떤 애플리케이션이든 최초에 로딩된다면, host가 될 수 있다. 예를 들어, 애플리케이션에서 라우팅이 바뀌거나 다른 페이지로 이동할 경우, federated된 모듈을 불러오게 되는데, 이는 dynamic import와 마찬가지로 동작하게 된다. 만약에 이동한 페이지에서 새로고침한다면, 그 지점이 host가 된다.

정리해서 예를 들어보자.

웹 애플리케이션에서 home 페이지에 들어갔다면, 이는 host가 된다. 만약 about 페이지로 간다면, host는 별도로 독립된 애플리케이션(about)을 동적으로 임포트 하게 된다. 이는 메인 entry point나 전체 애플리케이션을 로딩하는 것이 아니다. 단지 몇 kb 코드만 불러올 뿐이다. 만약 현재 상태에서 새로고침을 하면 about 페이지는 host가 되고, 뒤로가기를 시도할 경우 앞서 host였던 home을 remote로 불러오게 된다. 모든 애플리케이션은 리모트나 호스트가 될 수 있으며, 다른 federated된 모듈에 의해 실행 될 수 있다.

## federated application 만들어보기

`./src/App`을 `app_one_remote`라고 선언하였다. 이는 다른 애플리케이션에서 실행될 수 있다.

```javascript
const HtmlWebpackPlugin = require('html-webpack-plugin')
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')

module.exports = {
 // other webpack configs...
 plugins: [
 new ModuleFederationPlugin({
 name: 'app_one_remote',
 remotes: {
 app_two: 'app_two_remote',
 app_three: 'app_three_remote',
 },
 exposes: {
 AppContainer: './src/App',
 },
 shared: ['react', 'react-dom', 'react-router-dom'],
 }),
 new HtmlWebpackPlugin({
 template: './public/index.html',
 chunks: ['main'],
 }),
 ],
}
```

애플리케이션 헤드에, `app_one_remote.js`를 불러오도록 했다. 이렇게 하면 다른 웹팩 런타임에 연결되고, 런타임에 오케이스트레이션 계층을 프로비저닝 할 수 있다. 이는 특별히 설계된 웹팩 런타임과 진입점이다. 이는 일반적인 애플리케이션 진입점과 다르게, 몇 kb에 불과하다.

```html
<head>
 <script src="http://localhost:3002/app_one_remote.js"></script>
 <script src="http://localhost:3003/app_two_remote.js"></script>
</head>
<body>
 <div id="root"></div>
</body>
```

`App One`에서 `App Two`에 있는 코드를 사용하고 싶다면,

```javascript
const Dialog = React.lazy(() => import('app_two_remote/Dialog'))

const Page1 = () => {
 return (
 <div>
 <h1>Page 1</h1>
 <React.Suspense fallback="Loading Material UI Dialog...">
 <Dialog />
 </React.Suspense>
 </div>
 )
}

export default Page1
```

라우터는 일반적인 표준과 비슷하다.

```javascript
import { Route, Switch } from 'react-router-dom'

import Page1 from './pages/page1'
import Page2 from './pages/page2'
import React from 'react'

const Routes = () => (
 <Switch>
 <Route path="/page1">
 <Page1 />
 </Route>
 <Route path="/page2">
 <Page2 />
 </Route>
 </Switch>
)

export default Routes
```

App Two에서는 Dialog를 내보낼 것이며, 이는 위에서 봤던 것 처럼 App One에서 사용한다.

```javascript
const HtmlWebpackPlugin = require('html-webpack-plugin')
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')
module.exports = {
 plugins: [
 new ModuleFederationPlugin({
 name: 'app_two_remote',
 filename: 'remoteEntry.js',
 exposes: {
 Dialog: './src/Dialog',
 },
 remotes: {
 app_one: 'app_one_remote',
 },
 shared: ['react', 'react-dom', 'react-router-dom'],
 }),
 new HtmlWebpackPlugin({
 template: './public/index.html',
 chunks: ['main'],
 }),
 ],
}
```

루트 앱은 이런 모양이다.

```javascript
import React from 'react'
import Routes from './Routes'
const AppContainer = React.lazy(() => import('app_one_remote/AppContainer'))

const App = () => {
 return (
 <div>
 <React.Suspense fallback="Loading App Container from Host">
 <AppContainer routes={Routes} />
 </React.Suspense>
 </div>
 )
}

export default App
```

```javascript
import React from 'react'
import { ThemeProvider } from '@material-ui/core'
import { theme } from './theme'
import Dialog from './Dialog'

function MainPage() {
 return (
 <ThemeProvider theme={theme}>
 <div>
 <h1>Material UI App</h1>
 <Dialog />
 </div>
 </ThemeProvider>
 )
}

export default MainPage
```

`App Three`의 경우, `<App>`에서 실행되는 것이 없이 독립되어 있으므로, 아래와 같이 처리하면 된다.

```javascript
new ModuleFederationPlugin({
 name: "app_three_remote",
 library: { type: "var", name: "app_three_remote" },
 filename: "remoteEntry.js",
 exposes: {
 Button: "./src/Button"
 },
 shared: ["react", "react-dom"]
}),
```

트위터에 제작자가 공유해준 실제 코드를 살펴보자.

<iframe id="twitter-widget-2" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="true" class="" style="position: static; visibility: visible; width: 352px; height: 592px; display: block; flex-grow: 1;" title="Twitter Tweet" src="https://platform.twitter.com/embed/index.html?creatorScreenName=indepth_dev&amp;dnt=false&amp;embedId=twitter-widget-2&amp;frame=false&amp;hideCard=false&amp;hideThread=false&amp;id=1234383702433468416&amp;lang=en&amp;origin=https%3A%2F%2Findepth.dev%2Fwebpack-5-module-federation-a-game-changer-in-javascript-architecture%2F&amp;siteScreenName=https%3A%2F%2Ftwitter.com%2Findepth_dev%2F&amp;theme=light&amp;widgetsVersion=219d021%3A1598982042171&amp;width=550px" data-tweet-id="1234383702433468416"></iframe>

네트워크 탭을 살펴보면, 세 코드가 모두 다른 번들에 존재하고 있음을 알 수 있다.

의존성 중복이 존재하지 않는다. `shared` 옵션에 나와있듯, `remote`는 `host`의 의존성에 의존하게 된다. 만약 호스트에 해당 의존성이 존재하지 않는다면, 리모트는 알아서 다운로드 할 것이다.

`vendor`나ㅣ 다른 모듈을 `shared`에 추가하는 것은 확장성에 그다지 좋지 못하다. `AutomaticModuleFederationPlugin`를 제공하여, 웹팩 코어 외부에 있는 코드들을 관리할 수 있도록 할 것이다.

## Server Side Rendering

Module Federation은 브라우저 node 모든 환경에서 동작한다. 단지 서버 빌드가 commonjs 라이브러리 타겟을 사용하기만 하면 된다.

```javascript
module.exports = {
 plugins: [
 new ModuleFederationPlugin({
 name: 'container',
 library: { type: 'commonjs-module' },
 filename: 'container.js',
 remotes: {
 containerB: '../1-container-full/container.js',
 },
 shared: ['react'],
 }),
 ],
}
```

Module Federation에 대한 다양한 예제를 아래에서 살펴볼 수 있다.

- https://github.com/module-federation/module-federation-examples
- https://github.com/module-federation/next-webpack-5
- https://github.com/ScriptedAlchemy/mfe-webpack-demo
- https://github.com/ScriptedAlchemy/webpack-external-import

> 결과적으로 하나의 큰 애플리케이션을 여러개의 독립된 애플리케이션으로 만든 다음, 다이나믹 로딩을 하듯이 필요한 순간에 필요한 컴포넌트 (소스)를 불러오게 한다는 개념인 것 같다. webpack5 에 포함될 예정이라고 하니, 정식 출시 될 때 실제 동작하는 예제를 만들어보고 고민해봐야겠다.

자바스크립트 아키텍쳐의 게임체인저라고 하는데, 과연 그렇게 될 수 있을까?

Webpack Module Federation에 대해 알아보자

## Enum 이란

[Typescript의 enum](https://www.typescriptlang.org/docs/handbook/enums.html)은 열거형으로, 개발자로 하여금 열거된 세트의 constant를 사용할 수 있도록 한다.

```typescript
enum Direction {
  Up,
  Down,
  Left,
  Right,
}
```

이렇게 해두면, 각각 0, 1, 2, 3의 값을 가지게 된다.

```typescript
Direction.Up // 0
Direction.Down // 1
Direction.Left // 2
Direction.Right // 3
```

물론 아래 처럼 임의의 값을 넣을 수도 있다.

```typescript
enum Direction {
  Up = 'UP',
  Down = 'DOWN',
  Left = 'LEFT',
  Right = 'RIGHT',
}
```

눈치챘겠지만, enum은 자동으로 0, 1, 2, .. 의 숫자를 부여하므로, 문자열 enum을 만들기 위해서는 일일이 문자열을 작성해야 하는 귀찮음도 존재한다.

```typescript
// 보기에도 중복되어보이고, 귀찮다.
enum Day {
  Sunday = 'Sunday',
  Monday = 'Monday',
  Tuesday = 'Tuesday',
  Wednesday = 'Wednesday',
  Thursday = 'Thursday',
  Friday = 'Friday',
  Saturday = 'Saturday',
}
```

## Enum in javascript

문제는 자바스크립트에서는 이러한 기능이 없기 때문에, 이를 자바스크립트로 변환하면 아래와 같이 IIFE를 사용하게 된다.

```javascript
'use strict'
var Direction
;(function (Direction) {
  Direction['Up'] = 'UP'
  Direction['Down'] = 'DOWN'
  Direction['Left'] = 'LEFT'
  Direction['Right'] = 'RIGHT'
})(Direction || (Direction = {}))
```

그러나 번들러 입장에서, IIFE는 언제 쓰일 지 모르는 코드이기 때문에 섣불리 treeshaking을 하지 않게 된다.

[rollup의 예제 코드](https://rollupjs.org/repl/?version=2.26.11&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QkRpcmVjdGlvbiU3RCUyMGZyb20lMjAnLiUyRmVudW0uanMnJTVDbmltcG9ydCUyMCU3QmhlbGxvJTdEJTIwZnJvbSUyMCcuJTJGdHJlZXNoYWtlZCclNUNuaW1wb3J0JTIwJTdCaGklN0QlMjBmcm9tJTIwJy4lMkZub3RUcmVlc2hha2VkJyU1Q24lNUNuY29uc29sZS5sb2coaGVsbG8pJTVDbiUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmVudW0uanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyJ3VzZSUyMHN0cmljdCclNUNuZXhwb3J0JTIwdmFyJTIwRGlyZWN0aW9uJTVDbiUzQihmdW5jdGlvbiUyMChEaXJlY3Rpb24pJTIwJTdCJTVDbiUyMCUyMERpcmVjdGlvbiU1QidVcCclNUQlMjAlM0QlMjAnVVAnJTVDbiUyMCUyMERpcmVjdGlvbiU1QidEb3duJyU1RCUyMCUzRCUyMCdET1dOJyU1Q24lMjAlMjBEaXJlY3Rpb24lNUInTGVmdCclNUQlMjAlM0QlMjAnTEVGVCclNUNuJTIwJTIwRGlyZWN0aW9uJTVCJ1JpZ2h0JyU1RCUyMCUzRCUyMCdSSUdIVCclNUNuJTdEKShEaXJlY3Rpb24lMjAlN0MlN0MlMjAoRGlyZWN0aW9uJTIwJTNEJTIwJTdCJTdEKSklMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIydHJlZXNoYWtlZC5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjB2YXIlMjBoZWxsbyUyMCUzRCUyMCdoZWxsbyclMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIybm90VHJlZXNoYWtlZC5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjB2YXIlMjBoaSUyMCUzRCUyMCdoaSclMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyZXMlMjIlMkMlMjJuYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJhbWQlMjIlM0ElN0IlMjJpZCUyMiUzQSUyMiUyMiU3RCUyQyUyMmdsb2JhbHMlMjIlM0ElN0IlN0QlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==)

## const enum?

이와 비슷한 const enum이 있다.

```typescript
const enum Direction {
  Up = 'UP',
  Down = 'DOWN',
  Left = 'LEFT',
  Right = 'RIGHT',
}

const left = Direction.Left
```

위 코드는

```javascript
'use strict'
const left = 'LEFT' /* Left */
```

이렇게 변환된다. 순수 enum 보다 더 간결하고, 트리쉐이킹도 잘 될 것만 같다. 실제로도 잘된다. 그러나 문제가 있다.

### Isolated modules

만약 `const enum`과 이를 사용하는 코드가 각각 다른 모듈에 있다면 어떻게 될까? `const enum`의 값을 읽어오기에 위해 해당 코드가 존재하는 모듈도 실행해야 할 것이다. 그러나 만약 `--isolatedModules`가 켜져 있다면, 해당 작업을 수행할 수 없게 된다.

### babel

babel에서 `const enum`을 사용하기 위해서는 추가로 플러그인을 설치해야 한다.

https://github.com/dosentmatter/babel-plugin-const-enum

## Union을 쓰자.

```typescript
const Direction = {
  Up: 'UP',
  Left: 'LEFT',
  Right: 'RIGHT',
  Down: 'DOWN',
} as const

type Direction = typeof Direction[keyof typeof Direction]

for (const d of Object.values(Direction)) {
  console.log(d)
}
```

`as const`를 사용하여, `Direction`에 강한 const assertion을 추가했다. 이는 타입스크립트에서 타입추론의 범위를 줄이는 효과를 가져온다.

![as const를 사용하지 않았을 때](./images/not_as_const.png)

![as const 사용시](./images/as_const.png)

const로 선언했다 할지라도, 객체이기 때문에 바뀔 수 있는데 `as const`를 사용함으로써 `readonly`를 강제하는 효과를 낳았다.

## 참고

- https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/
- https://www.kabuku.co.jp/developers/good-bye-typescript-enum
- https://medium.com/@seungha_kim_IT/typescript-3-4-const-assertion-b50a749dd53b


typescript의 enum은 tree shaking이 되지 않는다?

<h2 id="enum-이란">Enum 이란</h2>
<a href="https://www.typescriptlang.org/docs/handbook/enums.html">Typescript의 enum</a>은 열거형으로, 개발자로 하여금 열거된 세트의 constant를 사용할 수 있도록 한다.
<pre class="language-typescript"><code class="language-typescript">enum Direction {
 Up,
 Down,
 Left,
 Right,
}
</code></pre>
이렇게 해두면, 각각 0, 1, 2, 3의 값을 가지게 된다.
<pre class="language-typescript"><code class="language-typescript">Direction.Up // 0
Direction.Down // 1
Direction.Left // 2
Direction.Right // 3
</code></pre>
물론 아래 처럼 임의의 값을 넣을 수도 있다.
<pre class="language-typescript"><code class="language-typescript">enum Direction {
 Up = 'UP',
 Down = 'DOWN',
 Left = 'LEFT',
 Right = 'RIGHT',
}
</code></pre>
눈치챘겠지만, enum은 자동으로 0, 1, 2, .. 의 숫자를 부여하므로, 문자열 enum을 만들기 위해서는 일일이 문자열을 작성해야 하는 귀찮음도 존재한다.
<pre class="language-typescript"><code class="language-typescript">// 보기에도 중복되어보이고, 귀찮다.
enum Day {
 Sunday = 'Sunday',
 Monday = 'Monday',
 Tuesday = 'Tuesday',
 Wednesday = 'Wednesday',
 Thursday = 'Thursday',
 Friday = 'Friday',
 Saturday = 'Saturday',
}
</code></pre>
<h2 id="enum-in-javascript">Enum in javascript</h2>
문제는 자바스크립트에서는 이러한 기능이 없기 때문에, 이를 자바스크립트로 변환하면 아래와 같이 IIFE를 사용하게 된다.
<pre class="language-javascript"><code class="language-javascript">'use strict'
var Direction
;(function (Direction) {
 Direction['Up'] = 'UP'
 Direction['Down'] = 'DOWN'
 Direction['Left'] = 'LEFT'
 Direction['Right'] = 'RIGHT'
})(Direction || (Direction = {}))
</code></pre>
그러나 번들러 입장에서, IIFE는 언제 쓰일 지 모르는 코드이기 때문에 섣불리 treeshaking을 하지 않게 된다.
<a href="https://rollupjs.org/repl/?version=2.26.11&#x26;shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QkRpcmVjdGlvbiU3RCUyMGZyb20lMjAnLiUyRmVudW0uanMnJTVDbmltcG9ydCUyMCU3QmhlbGxvJTdEJTIwZnJvbSUyMCcuJTJGdHJlZXNoYWtlZCclNUNuaW1wb3J0JTIwJTdCaGklN0QlMjBmcm9tJTIwJy4lMkZub3RUcmVlc2hha2VkJyU1Q24lNUNuY29uc29sZS5sb2coaGVsbG8pJTVDbiUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmVudW0uanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyJ3VzZSUyMHN0cmljdCclNUNuZXhwb3J0JTIwdmFyJTIwRGlyZWN0aW9uJTVDbiUzQihmdW5jdGlvbiUyMChEaXJlY3Rpb24pJTIwJTdCJTVDbiUyMCUyMERpcmVjdGlvbiU1QidVcCclNUQlMjAlM0QlMjAnVVAnJTVDbiUyMCUyMERpcmVjdGlvbiU1QidEb3duJyU1RCUyMCUzRCUyMCdET1dOJyU1Q24lMjAlMjBEaXJlY3Rpb24lNUInTGVmdCclNUQlMjAlM0QlMjAnTEVGVCclNUNuJTIwJTIwRGlyZWN0aW9uJTVCJ1JpZ2h0JyU1RCUyMCUzRCUyMCdSSUdIVCclNUNuJTdEKShEaXJlY3Rpb24lMjAlN0MlN0MlMjAoRGlyZWN0aW9uJTIwJTNEJTIwJTdCJTdEKSklMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIydHJlZXNoYWtlZC5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjB2YXIlMjBoZWxsbyUyMCUzRCUyMCdoZWxsbyclMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIybm90VHJlZXNoYWtlZC5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjB2YXIlMjBoaSUyMCUzRCUyMCdoaSclMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyZXMlMjIlMkMlMjJuYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJhbWQlMjIlM0ElN0IlMjJpZCUyMiUzQSUyMiUyMiU3RCUyQyUyMmdsb2JhbHMlMjIlM0ElN0IlN0QlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==">rollup의 예제 코드</a>
<h2 id="const-enum">const enum?</h2>
이와 비슷한 const enum이 있다.
<pre class="language-typescript"><code class="language-typescript">const enum Direction {
 Up = 'UP',
 Down = 'DOWN',
 Left = 'LEFT',
 Right = 'RIGHT',
}

const left = Direction.Left
</code></pre>
위 코드는
<pre class="language-javascript"><code class="language-javascript">'use strict'
const left = 'LEFT' /* Left */
</code></pre>
이렇게 변환된다. 순수 enum 보다 더 간결하고, 트리쉐이킹도 잘 될 것만 같다. 실제로도 잘된다. 그러나 문제가 있다.
<h3 id="isolated-modules">Isolated modules</h3>
만약 <code>const enum</code>과 이를 사용하는 코드가 각각 다른 모듈에 있다면 어떻게 될까? <code>const enum</code>의 값을 읽어오기에 위해 해당 코드가 존재하는 모듈도 실행해야 할 것이다. 그러나 만약 <code>--isolatedModules</code>가 켜져 있다면, 해당 작업을 수행할 수 없게 된다.
<h3 id="babel">babel</h3>
babel에서 <code>const enum</code>을 사용하기 위해서는 추가로 플러그인을 설치해야 한다.
<a href="https://github.com/dosentmatter/babel-plugin-const-enum">https://github.com/dosentmatter/babel-plugin-const-enum</a>
<h2 id="union을-쓰자">Union을 쓰자.</h2>
<pre class="language-typescript"><code class="language-typescript">const Direction = {
 Up: 'UP',
 Left: 'LEFT',
 Right: 'RIGHT',
 Down: 'DOWN',
} as const

type Direction = typeof Direction[keyof typeof Direction]

for (const d of Object.values(Direction)) {
 console.log(d)
}
</code></pre>
<code>as const</code>를 사용하여, <code>Direction</code>에 강한 const assertion을 추가했다. 이는 타입스크립트에서 타입추론의 범위를 줄이는 효과를 가져온다.
<img src="./images/not_as_const.png" alt="as const를 사용하지 않았을 때">
<img src="./images/as_const.png" alt="as const 사용시">
const로 선언했다 할지라도, 객체이기 때문에 바뀔 수 있는데 <code>as const</code>를 사용함으로써 <code>readonly</code>를 강제하는 효과를 낳았다.
<h2 id="참고">참고</h2>
<ul>
<li><a href="https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/">https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/</a></li>
<li><a href="https://www.kabuku.co.jp/developers/good-bye-typescript-enum">https://www.kabuku.co.jp/developers/good-bye-typescript-enum</a></li>
<li><a href="https://medium.com/@seungha_kim_IT/typescript-3-4-const-assertion-b50a749dd53b">https://medium.com/@seungha_kim_IT/typescript-3-4-const-assertion-b50a749dd53b</a></li>
</ul>

yceffort

Typescript 4.0 릴리즈 노트

Github Code Spaces 베타 당첨 및 후기

[Book] No Rules Rules

Webpack Module Federation에 대해 알아보자

typescript의 enum은 tree shaking이 되지 않는다?