`export default` 구문은 보통 파일 내에서 한개만 `export`하거나, 대표로 `export`할 것이 있을 때 많이 쓴다.

```typescript
function Foo {
  // ...
}

export default Foo
```

```typescript
export default function Foo {
  // ...
}
```

그리고 쓰는 쪽에서는 이렇게 `import`할 것이다.

```typescript
import Foo from './foo'
```

그런데 왜 이것을 않았으면 좋겠는지 몇 가지 이유를 들어서 설득해보자.

## Table of Contents

## 예제

`foo.ts`

```typescript
export default function Foo() {
  console.log('foo')
}
```

`bar.ts`

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

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

## 검색이 어렵다.

```typescript
import { h } from './bar'
```

default export를 하게 되면 내보내기가 있는지 여부가 불투명하다.

```typescript
import { Foo } from 'something'
```

그러나 기본값이 없으면 코드 intellisense로 내부에 어떤 것을 import 할 수 있는지 쉽게 알 수 있다.

![export](./images/export1.png)

## commonjs

`default`는 `commonjs`를 쓰는 사람들에게는 혼동을 준다. 위의 default export를 `commonjs`로 바꾸면

```javascript
export default function Foo() {
  console.log('foo')
}

module.exports = {
  Foo,
  default: Foo,
}
```

방식으로 해야하는 어려움이 있다.

## re-export

```typescript
export { default as Foo } from './foo'
```

```typescript
export * from './bar'
```

named export 쪽이 다시 export 하는데 있어서 훨씬 편하다.

## 다이나믹 import

```typescript
const foo = await import('./foo')
foo.default()
```

```typescript
const { hello } = await import('./bar')
hello()
```

`default` 한단계를 더 거쳐야 한다.

## 클래스나 함수가 아니면 한줄이 더 필요함.

```typescript
// 이건 안된다
export default const hello = 'hello'

// 이건 가능
export const hi = "hi";
```

```typescript
// 이렇게 해야한다.
const hello = 'hello'

export default hello
```

## 리팩토링의 어려움

`default export`는 가져다 쓰는 곳에서 네이밍을 제멋대로 할 수 있으므로, 리팩토링 하기가 어렵다.

```typescript
import Foo from './foo'
import Wow from './foo'
import Bye from './foo'
```

위 세개는 모두 동일하게 동작하기 때문에, 오타를 수정하는 등의 작업이 어려워 진다.

## 트리 쉐이킹

만약 여러개의 object를 하나의 `default export`로 내보내는 코드가 있다고 가정해보자.

`foo.ts`

```javascript
export default {
  foo1: 'foo1',
  bar1: 'bar1',
}
```

`bar.ts`

```javascript
export const bar2 = 'bar2'
export const foo2 = 'foo2'
```

`index.ts`

```javascript
import Foo from './foo'
import { foo2 } from './bar'

console.log(Foo.foo1)
console.log(foo2)
```

[이를 트리쉐이킹을 거치게 되면 아래와 같은 결과가 나온다.](https://rollupjs.org/repl/?version=2.33.1&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMEZvbyUyMGZyb20lMjAnLiUyRmZvbyclNUNuaW1wb3J0JTIwJTdCJTIwZm9vMiUyMCU3RCUyMGZyb20lMjAnLiUyRmJhciclNUNuJTVDbmNvbnNvbGUubG9nKEZvby5mb28xKSU1Q25jb25zb2xlLmxvZyhmb28yKSUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmJhci5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjBjb25zdCUyMGJhcjIlMjAlM0QlMjAnYmFyMiclNUNuZXhwb3J0JTIwY29uc3QlMjBmb28yJTIwJTNEJTIwJ2ZvbzInJTIyJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmZvby5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjBkZWZhdWx0JTIwJTdCJTVDbiUyMCUyMGZvbzElM0ElMjAnZm9vMSclMkMlNUNuJTIwJTIwYmFyMSUzQSUyMCdiYXIxJyUyQyU1Q24lN0QlMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyZXMlMjIlMkMlMjJuYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJhbWQlMjIlM0ElN0IlMjJpZCUyMiUzQSUyMiUyMiU3RCUyQyUyMmdsb2JhbHMlMjIlM0ElN0IlN0QlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==)

```javascript
var Foo = {
  foo1: 'foo1',
  bar1: 'bar1',
}

const foo2 = 'foo2'

console.log(Foo.foo1)
console.log(foo2)
```

`named exports`를 하는게 번들 사이즈를 더 줄이는데 도움을 준다.

## 결론

그럼에도 불구하고 default export를 쓰는 것을 그만두지는 않을 것 같다. `eslint-config-airbnb` 만 보더라도 [내보낼 것이 한개인 경우에는 default를 쓰는 것을 권장하고 있고](https://github.com/airbnb/javascript#modules--prefer-default-export) `nextjs` 등의 라이브러리에서도 `default export`를 하지 않고서는 할 수 없는 기능들이 더러 있다.

[물론 여전히 두 export 방식에 대해서는 논란이 많지만](https://github.com/airbnb/javascript/issues/1365) 아무래도 `default` 가 깔끔한 건 기분 탓일까, 습관 탓일까 🤔

그래도 **가급적이면** named exports를 하는 방향으로 코드를 써보자. 그럼에도 `default`는 죄가 없는 것 같다.


근데 쓰는게 뭔가 더 안정적인 기분이야

export default를 쓰지 말아야 할 이유

한 사이트가 여러 탭에서 떠 있을 때, 탭 사이에서 통신이 필요한 경우가 있을까?

- 한 탭에서 사이트의 테마를 변경해서 다른 탭에 있는 사이트에까지 변경이 필요한 경우
- 애플리케이션의 상태를 탭 사이에 맞춰야 하는 경우
- 가장 최근에 가져온 인증 정보를 브라우저 탭 간에 공유가 필요한 경우

이를 달성할 수 있는 방법이 무엇이 있을까?

## Local Storage

놀랍게도 [로컬 스토리지에도 event를 지원한다.](https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event) 이 event를 활용해서 localStorage의 변화를 감지하는 방법이다.

```javascript
React.useEffect(() => {
  function listener(event: StorageEvent) {
    if (event.storageArea !== localStorage) return
    if (event.key === LOGGINED) {
      setLoginTime(parseInt(event.newValue || '0', 10))
    }
  }
  window.addEventListener('storage', listener)

  return () => {
    window.removeEventListener('storage', listener)
  }
}, [])
```

https://codesandbox.io/s/tab-communications-1-localstorage-5ldjw

![example1](./images/tab-communication-1.gif)

잘 작동하는 것 같지만 몇가지 문제가 존재한다.

- 정확히는 탭 별로 이벤트가 발생하는게 아니고 storage의 event를 가져다 쓰는 꼼수라는 점
- localStorage는 동기로 작동하기 때문에 메인 UI 쓰레드를 블로킹할 수도 있음.

## Broadcast Channel API

[BroadCast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API)는 탭, 윈도우, 프레임, iframe 그리고 Web worker 간에 통신을 할 수 있게 해주는 API다.

이 방법을 쓰면, [브라우저 콘텍스트](https://developer.mozilla.org/en-US/docs/Glossary/browsing_context) 간에 통신이 가능해진다.

```javascript
const LOGGINED = "loggedIn";

const channel = new BroadcastChannel(LOGGINED);

export default function App() {
  const [loginTime, setLoginTime] = React.useState<number>(() =>
    parseInt(window.localStorage.getItem(LOGGINED) || "0", 10)
  );

  React.useEffect(() => {
    function listener(event: MessageEvent) {
      setLoginTime(event.data);
    }

    channel.addEventListener("message", listener);

    return () => {
      channel.removeEventListener("message", listener);
    };
  }, []);

  return (
    // jsx
  );
}
```

https://codesandbox.io/s/tab-communications-2-braodcast-channel-m50d6

~~코드가 어딘가 이상하다면 그냥 무시해주셈~~

![example2](./images/tab-communication-2.gif)

다만 문제점은 [Broadcast Channel Api는 너무 힙한 나머지 사파리와 IE에서 쓸 수 없다는 점](https://caniuse.com/broadcastchannel)ㅣ다.

## Service Worker

[서비스 워커](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration)를 이용하는 방법도 있다.

```javascript
window.navigator.serviceWorker.controller?.postMessage({
  [LOGGINED]: currentDateTime,
})
```

그리고 이 정보를 서비스워커에서 받으면 된다. 그러나 서비스 워커를 세팅하는 것은 쉽지 않고, 추가적으로 `serviceWorker.js`등을 만드는 등의 노력이 필요하다. 그리고 [서비스 워커도 마찬가지로 IE에서 지원하지 않는다.](https://caniuse.com/serviceworkers)

## postMessage

가장 전통적이고도 널리 쓰이는 방식은 [window.postmessasge](https://developer.mozilla.org/ko/docs/Web/API/Window/postMessage)다. 아마 대다수의 서비스들이 이 방식을 쓰고 있을 것이다.

```javascript
targetWindow.postMessage(message, targetOrigin)
```

```javascript
window.addEventListener(
  'message',
  (event) => {
    if (event.origin !== 'http://localhost:8080') return
    // Do something
  },
  false,
)
```

이 방법의 장점은 cross-origin을 지원한다는 것이다. 그러나 단점은 위 코드에서 알 수 있듯이 브라우저 탭의 레퍼런스를 가지고 있어야 한다. (`targetWindow`를 가지고 있는 것 같이) 그래서 이 방식은 `window.open()`이나 `document.open()`을 통해서 탭을 열었을 때만 사용 가능하다.

https://caniuse.com/mdn-api_window_postmessage


블로그 다크모드 지원시에 고려해보겠습니다 🤔

브라우저 탭 사이에서 통신 하는 방법

https://yceffort.kr/2020/09/webpack-module-federation 에서 이어진다.

webpack 5가 발표 되면서 동시에 module federation도 직접해볼 수 있게 되었다. 한번 직접 적용해보면서 정말로 게임 체인저가 될 수 있는지 살펴보자.

해당 예제 프로젝트 저장소는 [여기](https://github.com/yceffort/webpack-module-federation-exmaple)다.

react v17과 webpack 5를 바탕으로, 아주 기초적인 세팅만 해서 빠르게 개발을 진행해보았다.

## main 설정

일단 메인 프로젝트가 있고, 여기저기에 있는 컴포넌트를 가져다 쓰는 모습을 상상해보면서 프로젝트를 만들어보자. main은 module federation으로 서빙되는 다른 프로젝트를 가져다가 쓰는 federation의 중심이라고 보면 될 것 같다.

`webpack.config.js`

```javascript
const path = require('path')

const HtmlWebpackPlugin = require('html-webpack-plugin')
const { ModuleFederationPlugin } = require('webpack').container

module.exports = {
  entry: './src/index',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3001,
  },
  output: {
    publicPath: 'http://localhost:3001/',
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options: {
          presets: ['@babel/preset-react'],
        },
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'main',      
      remotes: {
        app1: 'app1',
      },
      shared: ['react', 'react-dom'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
}
```

[ModuleFederationPlugin](https://webpack.js.org/concepts/module-federation/)을 사용한 것을 볼 수 있다. 이 플러그인은 `ContainerPlugin`과 `ContainerReferencePlugin` 를 합친 개념이라고 보면 될 것 같다.

여기는 단순히 expose 한 다른 federation을 가져다 쓰는 역할만 하기 때문에, `exposes`를 하기 않고 있다. 

## app1 설정

`main`에서 가져다 쓸 실제 컴포넌트를 expose하는 곳이다.

`webpack.config.js`

```javascript
const path = require('path')

const HtmlWebpackPlugin = require('html-webpack-plugin')
const { ModuleFederationPlugin } = require('webpack').container

module.exports = {
  entry: './src/index',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3002,
  },
  output: {
    publicPath: 'http://localhost:3002/',
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options: {
          presets: ['@babel/preset-react'],
        },
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      library: { type: 'var', name: 'app1' },
      filename: 'remoteEntry.js',
      exposes: {
        './Counter': './src/components/counter/index.jsx',
      },
      shared: ['react', 'react-dom'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
}
```

`main`과 차이점은 `exposes`가 있다는 것이다. 여기에서는 간단한 `Counter`를 내보내도록 하고 있다. 그리고 이렇게 내보낸 `Counter`를 `https://localhost:3000/remoteEntry.js`에서 서비스 하도록 설정해주었다.

## main

`index.html`

```html
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Main App</title>
</head>

<body>
    <div id="root"></div>
    <script src="http://localhost:3002/remoteEntry.js"></script>
</body>

</html>
```

아까 서빙하기로 작성해둔 `remoteEntry.js`를 땡겨오는 모습이다. 물론 더 빠르게 만들기 위해서는 async 등을 사용할 수 도 있다.

`bootstrap.js` 

이름이 `bootstrap`인 이유는 공식 문서에서 그렇게 하고 있길래 그렇게 했다. 👀 뜻과도 연관이 있을듯.

```javascript
import React, { Suspense } from 'react'
import ReactDOM from 'react-dom'

const Counter = React.lazy(() => import('app1/Counter'))

function App() {
  return (
    <>
      <h1>Hello from React component</h1>
      <Suspense fallback="Loading Counter...">
        <Counter title={'hello, counter'} />
      </Suspense>
    </>
  )
}

ReactDOM.render(<App />, document.getElementById('root'))
```

`React`의 `lazy`와 `suspense`를 활용하여 `app1`에서 expose한 `Counter`를 가져다 쓰고 있다.


## 결과

카운터가 잘 나오고 있고

![result1](./images/module-federation-result1.png)

정상적으로 `remoteEntry`에서 가져다 쓰는 것을 볼 수 있다.

![result2](./images/module-federation-result2.png)

그리고 두 컴포넌트 모두 `share`로 `['react', 'react-dom']`을 쓰고 있었는데, 이것 역시 중복되지 않고 `main`에서 묶어서 쓰고 있는 것을 알 수 있었다.

## 좋은 점 내지는 기대하는 미래

요즘 유행이라고 하는 [Micro Frontend](https://micro-frontends.org/)를 달성할 수 있는 좋은 방법 중 하나 인 것 같다. 하나의 앱이 덩치가 너무 커서, 싱글 폴트의 위험 내지는 개발환경에서 쓸 데 없이 다 불러와야 하는 문제 등등이 존재하는데, module federation이 그것을 훌륭하게 해결해 줄 수 있을 것 같다. (물론 `main`이 고장나버리면 답이 없겠지만) 

![vertical](https://micro-frontends.org/ressources/diagrams/organisational/verticals-headline.png)

## 아쉬운 점

문서가 잘 나와있으면 좋을 것 같은데 아직 webpack의 문서가 좀 부실한 것 같다.

그래서

- https://github.com/webpack/webpack/blob/master/lib/container/ContainerPlugin.js
- https://github.com/webpack/webpack/blob/master/lib/container/ContainerReferencePlugin.js
- https://github.com/webpack/webpack/blob/master/lib/container/ModuleFederationPlugin.js
- https://github.com/module-federation/module-federation-examples

를 그냥 참고 하면서 했다. 다른 여타 기능들 처럼 webpack document에서 옵션으로 들어갈 수 있는 object의 특징이나 값을 명시해주었으면 좋겠다. 

https://webpack.js.org/concepts/module-federation/#containerplugin-low-level

아직은 문서가 그냥 아주 간단한 예제와 컨셉정도만 보여주고 있어서 아쉽다.

이러한 Documentation의 아쉬움 말고는 아직 이렇다할 단점을 느끼지 못했다. (물론 대규모 서비스에 직접 써보지는 않았지만) 향 후에 `create-react-app`이라든지, 다른 프론트엔드 생태계에서 적극적으로 사용되어서 더욱 발전해나갔으면 좋겠다.

## 다양한 예제들

더욱 다양한 예제들은 [여기](https://github.com/module-federation/module-federation-examples)에서 볼 수 있다.


Webpack Module Federation 직접해보기

[eslint-config-yceffort](https://github.com/yceffort/eslint-config-yceffort)를 사용하면서 개인적으로 굉장히 만족도가 높아졌다. 하지만 한가지 아쉬운 것은 테스트 코드가 없다는 것과, 배포를 할 때 별도의 절차 없이 내 로컬에서 그때 그때 수동으로 하고 있다는 것이었다. 여기에도 CI CD절차가 있다면 좋다고 생각했다.

## 방법1

간단한 방법으로는, 올바른 코드를 작성한다음에, 해당 코드를 `test`시에 `eslint`를 돌리는 방법이다.

`./tests/.eslintrc`

```json
{
  "extends": ["../index"],
  "rules": {
    // your custom rules..
  }
}
```

`camelcase.test.js`

```javascript
const hello_world = 'hello_world'
console.log(hello_world)
```

나의 eslintrc 옵션에서는 `camelcase`가 off로 되어 있고, 정상적으로 off가 되어 있다면 test 시에 eslint 에러가 나지 않을 것이다.

하지만 이 방법은 아쉽게도, lint가 정상적으로 작동하는지에 대해서만 알 수 있을 뿐, eslint가 실패시 원하는 에러가 뜨는지, 경고가 떴을 경우에는 해당 경고가 뜨는지 까지는 알 수 없다.

## 방법2

확실한 방법은 [eslint-nodejs-api](https://eslint.org/docs/developer-guide/nodejs-api)를 사용하는 것이다. nodejs api 레벨에서 테스트를 해보고, 그 결과를 가지고 좀더 정확히 분석하는 방법이다.

```javascript
const { ESLint } = require('eslint')
const config = require('../../../index')
const {
  rules: { curly },
} = require('../../../rules/style')

const RULE_ID = 'curly'

const eslint = new ESLint({
  // 특정 룰만 가져온 이유는, 다른 룰로 인해서 에러가 나는 것을 방지하기 위해서다.
  // 즉 순수하게 테스트 하고 싶은 룰에 대해서만 룰을 집어 넣었다.
  baseConfig: { ...config, rules: { curly } },
})

describe('eslint-config-yceffort curly', function () {
  it('right curly', async function () {
    const [result] = await eslint.lintFiles([`${__dirname}/curly.right.js`])

    const errors = result.messages.some((message) => message.ruleId === RULE_ID)

    // 올바른 케이스이기 때문에 true로 비교 하고 싶어서 이렇게 했다.
    expect(!errors).toBe(true)
  })

  it('wrong curly', async function () {
    const [result] = await eslint.lintFiles([`${__dirname}/curly.wrong.js`])

    const errors = result.messages.some((message) => message.ruleId === RULE_ID)

    // 잘못된 케이스이기 때문에 false로 비교 하고 싶어서 이렇게 했다.
    expect(!errors).toBe(false)
  })
})
```

`curly.wrong.js`

```javascript
if (true) {
  if (true) console.log('hello')
}
```

`curly.right.js`

```javascript
if (true) {
  for (let i of [1, 2, 3, 4, 5]) {
    console.log(i)
  }
}
```

github workflow 결과: https://github.com/yceffort/eslint-config-yceffort/runs/1345142937?check_suite_focus=true

## 결론

방법1은 작성하기 간단한 반면, 아주 정확하게 거를 수가 없다는 단점이 있고, 방법2는 작성하기엔 빡세지만 원하는 만큼 다양한 케이스에 대해서 테스트 코드를 작성할 수 있다는 장점이 있다.

방법2로 우리 조직의 `eslint-config`도 관리해보고 싶었지만, test case 작성이 너무 어렵다는 이유로 방법1을 선택했다. 🤔 (서운하지 않습니다.) 아무도 안쓰는 내 `eslint-config-yceffort`는 저렇게 관리해봐야겠다.


eslint-config 를 위한 테스트 코드를 작성하기 (CI)

[이 글](https://v8.dev/features/promise-combinators)을 번역 하고 요약했습니다.

| name                 | description                                     |                                                                      |
| -------------------- | ----------------------------------------------- | -------------------------------------------------------------------- |
| `Promise.allSettled` | does not short-circuit                          | this proposal 🆕                                                     |
| `Promise.all`        | short-circuits when an input value is rejected  | added in ES2015 ✅                                                   |
| `Promise.race`       | short-circuits when an input value is settled   | added in ES2015 ✅                                                   |
| `Promise.any`        | short-circuits when an input value is fulfilled | [separate proposal](https://github.com/tc39/proposal-promise-any) 🔜 |

## Promise.all

Promise를 배열로 받을 수 있으며, 모두 실행이 끝나거나 이 중 하나라도 reject 되면 끝나게 된다.

유저가 버튼을 클릭했을 때, CSS를 모두 다운로드 해서 완전히 새로운 UI를 그려주는 스펙을 상상해보자.

```javascript
const promises = [
  fetch('/component-a.css'),
  fetch('/component-b.css'),
  fetch('/component-c.css'),
]
try {
  const styleResponses = await Promise.all(promises)
  enableStyles(styleResponses)
  renderNewUi()
} catch (reason) {
  displayError(reason)
}
```

모든 요청이 성공해야 렌더링이 필요할 것이다. 만약 여기에서 하나라도 오류를 뱉게 된다면, 다른 작업이 끝나는 것을 기다리지 않고 바로 종료한다.

## Promise.race

`Promise.race`는 여러 개의 promise를 실행시킬 때, 아래와 같은 상황에서 유용하다.

1. 하나라도 먼저 끝나는 것을 원하는 경우
2. 바로 Promise가 리젝트 되었을 때 실행되길 원하는 경우

즉, Promise 중 하나가 거부되면 즉시 오류를 개별적으로 처리하게 된다.

```javascript
try {
  const result = await Promise.race([
    performHeavyComputation(),
    rejectAfterTimeout(2000),
  ])
  renderResult(result)
} catch (error) {
  renderError(error)
}
```

위 예제에서는 시간이 오래 걸리는 연산을 수행하거나, 2초후에 리젝트 되는 함수와 경쟁을 한다. 성공 또는 실패 중 첫번째로 실행되는 결과에 따라서 결과 또는 오류메시지를 처리할 수 있다.

## Promise.allSettled

`Promise.allSettled`는 모든 Promise 들이 종료되면, 성공과 실패와 상관없이 실행된다.
이는 Promise의 성공 실패가 중요하지 않고 단순히 종료되는 것을 확인하고 싶을 때 유용하다. 예를 들어, 모든 Promise가 끝나고 나면 로딩 스피너를 없애는 케이스가 존재할 수 있다.

```javascript
const promises = [
  fetch('/api-call-1'),
  fetch('/api-call-2'),
  fetch('/api-call-3'),
]

await Promise.allSettled(promises)
// 성공 실패와 관련없이 모두 종료가 되면 실행된다.
removeLoadingIndicator()
```

## Promise.any

`Promise.any`는 Promise가 하나라도 실행이 종료되면 실행된다는 점이 `Promise.race`와 유사하다. 다만 다른 점은, 하나가 실패한다고 해서 종료되지 않는다.

```javascript
const promises = [
  fetch('/endpoint-a').then(() => 'a'),
  fetch('/endpoint-b').then(() => 'b'),
  fetch('/endpoint-c').then(() => 'c'),
]
try {
  const first = await Promise.any(promises)
  // 첫번째로 성공한 Promise
  console.log(first)
  // → e.g. 'b'
} catch (error) {
  // 모든 Promise가 거절될 경우
  console.assert(error instanceof AggregateError)
  // 실패한 값을 프린트 한다.
  console.log(error.errors)
  // → [
  //     <TypeError: Failed to fetch /endpoint-a>,
  //     <TypeError: Failed to fetch /endpoint-b>,
  //     <TypeError: Failed to fetch /endpoint-c>
  //   ]
}
```

`Promise.any`에서 두 개 이상의 에러가 날 경우, 한번에 여러 에러들을 합칠 수 있는 [AggregateError](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AggregateError)를 사용할 수도 있다.

```javascript
Promise.any([Promise.reject(new Error('some error'))]).catch((e) => {
  console.log(e instanceof AggregateError) // true
  console.log(e.message) // "All Promises rejected"
  console.log(e.name) // "AggregateError"
  console.log(e.errors) // [ Error: "some error" ]
})
```


yceffort

javascript

export default를 쓰지 말아야 할 이유

브라우저 탭 사이에서 통신 하는 방법

Webpack Module Federation 직접해보기

eslint-config 를 위한 테스트 코드를 작성하기 (CI)

Promise 관련 API 살펴보기