Lighthouse는 웹사이트의 성능을 측정하는 유명한 도구중 하나다. 이 Lighthouse를 CI와 연동하여 수시로 웹사이트의 성능을 점검할 수 있도록 해보자.

일단 lighthouse-ci는 [여기](https://github.com/GoogleChrome/lighthouse-ci)에서 확인할 수 있다.

## Local에서 사용하기

1. 설치
   ```bash
   npm install -g @lhci/cli
   ```
2. 루트 디렉토리에서 `lighthouserc.js`를 만들자. 여기가 [설정](https://github.com/GoogleChrome/lighthouse-ci/blob/v0.4.1/docs/configuration.md#configuration-file)이 들어가는 곳이다.
   ```javascript
   module.exports = {
     ci: {
       collect: {
         /* Add configuration here */
       },
       upload: {
         /* Add configuration here */
       },
     },
   }
   ```
3. Lighthouse CI가 실행 될때마다, 서버가 구동되어 사이트가 시작되어야 한다. 이 서버가 작동하게되면, Lighthouse CI가 해당 서버를 토대로 웹사이트 성능을 추적할 것이다. 작업이 끝나면, 알아서 종료된다. 제대로 작동하기 위해서는 둘 중에 하나를 설정해둬야 한다.
   1. `staticDir`: `ci.collect`에 해당 속성과 함께 static 파일이 위치한 곳을 설정해 두면된다. 그러면 Lighthouse CI는 알아서 그 파일을 기준으로 서버를 실행해서 테스트를 하게 된다.
   2. `startServerCommand`: static한 사이트가 아니라면, `ci.collect`에 서버를 키는 명령어를 적어두면 된다. (`npm run start`) 그러면 Lighthouse CI는 알아서 해당 명령어를 실행해서 서버를 키고, 끝난 후에는 종료 시킬 것이다.
4. `ci.collect.url`에 Lighthouse CI가 조사해야 할 주소를 적어두면 된다. 값은 배열로 설정해야 하며, 이말인 즉슨 여러개의 사이트를 적어둘 수 있다는 뜻이다. 기본값으로 해당 주소를 각 3번씩 조사한다.
5. `ci.upload.target`에 `temporary-public-storage`로 설정해두자. Lighthouse CI가 조사한 결과 레포트를 해당 위치에 업로드 할 것이다. 이 결과는 최대 7일까지 유지되며 이후에는 자동으로 삭제된다. 자세한 내용은 [여기](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md#target)를 확인하자.
6. `ci.collect.numberOfRuns`에 숫자를 넣어두면, 몇번을 실행할지 설정할 수 있다.
7. 설정이 끝났다면 실행하자. `lhci autorun` 정상적으로 설정해두었다면, 아래와 같이 결과가 나타날 것이다.

```javascript
module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000'],
      collect: {
        numberOfRuns: 5,
      },
    },
    upload: {
      startServerCommand: 'npm run start',
      target: 'temporary-public-storage',
    },
  },
}
```

```bash
yceffort@yceffort yceffort-blog-v2 % lhci autorun
✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Started a web server with "npm run start"...
Running Lighthouse 5 time(s) on http://localhost:3000
Run #1...done.
Run #2...done.
Run #3...done.
Run #4...done.
Run #5...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:3000/...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1617202753232-29187.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.
```

## CI와 연계하기

Lighthouse CI는 다양한 CI 툴과 연계할 수 있다. [여기](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md#configure-your-ci-provider)를 참고하면 관련된 가이드를 참조할 수 있다.

또한 성능 모니터링에서 한 걸음 더 나아가서 사전에 정의된 기준을 충족하지 못하는 경우 빌드에 실패하게 만들 수 있다. 이는 [assert](https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/configuration.md#assert)를 이용해서 작업할 수 있다.

Lighthouse CI 에서는 세가지 단계로 검사할 수 있다.

- `off`: 무시
- `warn`:
- `error`: 이 경우 0가 아닌 값으로 종료된다.

```javascript
module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', { minScore: 1 }],
        'categories:accessibility': ['error', { minScore: 1 }],
      },
    },
    upload: {
      // ...
    },
  },
}
```

## github action과 연동하기

나의 최애이자 유일신(?) 은 github action이기 때문에, 여기에 연동을 해보려고 한다. (oss님 제발...)

1. `.github/workflows`에 원하는 이름으로 파일을 만든다. 나는 `lightouse-ci.yaml`로 했다.
2. 해당 파일 내용을 다음과 같이 꾸몄다.
   ```yaml
   name: Build project and run Lighthouse CI
   on: [push]
   jobs:
     lhci:
       name: Lighthouse CI
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v1
         - name: Use Node.js 12.x
           uses: actions/setup-node@v1
           with:
             node-version: 12.x
         - name: npm ci
           run: |
             npm ci
         - name: run build
           run: npm run build-nextjs
         - name: run Lighthouse CI
           run: |
             npm install -g @lhci/cli@0.3.x
             lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
   ```
   1. nodejs 설치
   2. npm ci
   3. 프로젝트 빌드
   4. lhci 설치 및 실행
3. assert 를 추가
   ```javascript
   module.exports = {
     ci: {
       collect: {
         url: ['http://localhost:3000'],
         collect: {
           numberOfRuns: 5,
         },
       },
       upload: {
         startServerCommand: 'npm run start',
         target: 'temporary-public-storage',
       },
       assert: {
         preset: 'lighthouse:recommended',
       },
     },
   }
   ```

이제 코드를 푸쉬하면 아래와 같이 작동하는 것을 볼 수 있다.

https://github.com/yceffort/yceffort-blog-v2/pull/278

![image1](./images/lighthouse-ci-github-action1.png)

![image2](./images/lighthouse-ci-github-action2.png)

추가로 [여기](https://github.com/apps/lighthouse-ci)를 방문해서 app을 설치하고 레파지토리에 `LHCI_GITHUB_APP_TOKEN`를 키값으로 값을 추가해준다면, PR에 메시지도 남겨준다. 물론, secret 추가 이후에는 아까 만들었던 github action yaml 도 변경해주어야 한다.

```yaml
- name: run Lighthouse CI
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
  run: |
    npm install -g @lhci/cli@0.3.x
    lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
```

## 후기

나름 블로그 최초 개설 시엔 신경을 썼었는데 시간이 지나고 이것저것 덕지덕지 붙으면서 점수가 점점 바닥으로 가고 있는 중이라는 것을 이제 알게 되었다. 🤪

여기서 개선은 모르겠고,,, 블로그 v3.0을 계획하고 있습니다. 블로그 v3.0 작업시에 lighthouse 점수를 수시로 확인하면서 작업을 해야겠다. 그리고 지금 내가 몸담고 있는 프로젝트에도 Lighthouse CI를 들이밀어 봐야겠다. 라이트하우스 함무바라 (점수보고) 디진다 퍼뜩 무봐라

![try lighthouse](https://mgall.app/api/file/9477923)


github workflow로 lighthouse ci 추가하기

## github workflow로 cron 사용

github action이 생긴 이후로 workflow를 활용해서 cron job을 처리하고 있었다.

```yaml
name: cron

on:
  schedule:
    - cron: '0 5 * * 1-5'

jobs:
  cron:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-node@v1
        with:
          node-version: '12'
          check-latest: true

      - name: CI
        run: |
          npm ci
      - name: Run Cron
        run: |
          npm run job
```

그러나 언제선가 부터 작업 시작 시간이 굉장히 안맞기 시작했다. 공짜로 사용하는 것이다 보니, 그러려니 하고 넘어갔었는데 예상 시간 보다 40~50분 넘어가서 작업이 실행되었다. 심지어 09시 (utc 기준 00시)에 실행되는 작업은 2시간 뒤에 실행되곤 했다.

![workflow-cron](./images/workflow-cron.png)

> 00시에 걸어둔 작업이었는데 실제로는 02시 30분에 실행되었다. github도 이런 문제가 있을수 있다는 걸 아는건지(?) 실제 실행시간이 표시되고 있지는 않았다.

그러나 이런 문제는 나만 겪는 것은 아닌듯 했다.

- https://stackoverflow.com/questions/65132563/why-is-github-actions-workflow-scheduled-with-cron-not-triggering-at-the-right-t
- https://github.community/t/github-actions-on-schedule-executed-in-delay/152972

github이 뭔가 조치를 취해주기를 기다렸지만(?) 포스팅 작성 시간 현재 (1월 24일) 까지 문제는 계속되었다. 그리고 별개로 로그를 살펴보니 이러한 증상은 2021년 들어서 더 심해진 것 같았다.

그래서 firebase의 cloud function으로 갈아탔다. 단순히 http요청으로 함수를 실행하게 도와주는 것 뿐만 아니라 cron으로 정해진 작업을 실행할 수도 있었다.

```javascript
exports.cronJob = functions.pubsub
  .schedule('0 14 * * 1-5')
  .timeZone('Asia/Seoul')
  .onRun((_) => {
    job()
  })
```

github과 다르게 시간대도 설정할 수 있어서 좋았다 (github에서는 몇 번 이점을 까먹고 새벽에 스케쥴이 돌아가기도 했다.) 한가지 배운 것은, `firebase init`으로 function을 초기화 할 경우 기본 디렉토리가 `./functions`로 설정되는데, 이를 다음과 같이 설정하면 root로 바꿀 수 있다.

**firebase.json**

```json
{
  "functions": {
    "source": ".",
    "runtime": "nodejs12"
  }
}
```

![functions](./images/functions-cron.png)

당연히 작업도 원하는 시간대에 정확하게 실행되었다.

언제부터인가 AWS를 안쓰고, GCP와 firebase를 위주로 계속 쓰고 있는데 나쁘지 않은 것 같다. 적어도 인터페이스는 GCP와 firebase가 더 나은 것 같다. 내가 구글빠라서 그런걸 수도 있고.


Github action cron이 제시간에 실행되지 않는 문제

## Table of Contents

[원문](https://reactjs.org/blog/2020/08/10/react-v17-rc.html)을 대충 요약한 글입니다.

## 새로운 기능은 없다.

리액트 17.0은 새로운 버전이 기능이 추가되는 대신에, 리액트 그 자체의 업그레이드에 초점을 두고 있다.

## 점진적 업그레이드

이전까지 리액트 버전 업그레이드는, 중간이 없었다. 이전 버전을 유지하거나, 새버전을 깔거나 둘중에 하나 였다. 이 전략이 슬슬 한계에 부딪히고 있다. 예를 들어 [legacy context api](https://reactjs.org/docs/legacy-context.html)의 경우에는 이를 자동으로 업그레이드할 방법이 존재 하지 않는다. 대부분의 애플리케이션이 이 api를 쓰고 있지 않지만, react에서는 여전히 이들을 지원해야 한다. 그래서 구 버전 앱들을 뒤로 남겨두고 지원을 하지 않을지, 아니면 계속해서 지원해야할지를 선택해야 하는데, 두 방법 모두 좋지는 않다. 따라서 새로운 방법을 염두해 두고 있다.

### 리액트 17에서는 점진적으로 업그레이드가 가능하다.

이전 버전 업그레이드는, 전체 앱을 한번에 업그레이드 해야 했다. 이는 오래되거나 관리되지 않은 코드에서 사용하기에는 너무나 힘든 문제였다. 그래서 이후 부터는 두가지 옵션을 주려고 한다. 첫번째 옵션은 이전에 그랬던 것 처럼 한번에 전체 애플리케이션을 업데이트 하는 것이다. 그리고 다른 하나는 점진적으로 하나씩 업그레이드 하는 것이다. 예를 들어, 대부분의 앱을 리액트 18로 올릴 수 있지미나, lazy-loading 다이얼러그나 일부 라우트는 리액트 17 상태로 둘 수 있는 것이다.

그렇다고 꼭 점진적 업그레이드를 해야하는 것은 아니다. 여전히, 한번에 앱을 업그레이드 하는 것이 최선의 해결책이다. 그러나 사이즈가 큰 애플리케이션의 경우 이러한 옵션을 선택하기에 무리가 있을 수 있으며, 리액트 17부터 그것을 지원하려고 한다.

이런 점진적 업그레이드를 위해서는 리액트 이벤트 시스템을 몇가지 변경해야 하고, 이러한 변화가 breaking change가 될 수 있어서 메인 버전을 업데이트 하였다. 약 10만개 이상의 컴포넌트 들 중에, 실제로 변화가 있을 것으로 예상되는 것은 20개 정도다.

[데모버전](https://github.com/reactjs/react-gradual-upgrade-demo/) 레포를 참고해보자.

## 이벤트 위임의 변화

먼저 리액트에서 이벤트 핸들러를 붙이는 코드를 살펴보자

```jsx
<button onClick={handleClick}>
```

바닐라 DOM에서는 이렇게 작동할 것이다.

```javascript
myButton.addEventListener('click', handleClick)
```

그러나 대부분의 이벤트의 경우, 리액트는 이벤트가 실제 선언된 DOM에 붙이지 않는다. 대신, 리액트는 하나의 이벤트당 하나의 핸들러를 document node에 붙인다. 이는 이벤트 위임이라고 불린다. 큰 어플리케이션 구조에서 성능의 이점을 볼 수 있는 것 이외에도, [replaying events](https://twitter.com/dan_abramov/status/1200118229697486849)와 같은 기능을 추가할 때도 유용하게 사용할 수 있다.

리액트는 첫 릴리즈 때 부터 이벤트 위임을 자동으로 실행해 왔다. DOM이벤트가 도큐먼트에서 실행되면, 리액트는 어떤 컴포넌트에서 실행되어야 하는지 살펴보고, 리액트는 해당 컴포넌트에서 부터 위로 버블링을 시작한다. 그러나 이 뒤에는, 리액트가 이미 이벤트 핸들러를 붙인 곳에서 네이티브 이벤트가 이미 도큐먼트 레벨까지 버블링되어 있었다.

그러나, 이부분이 점진적 업그레이드 전략에서 문제가 되었다.

만약 페이지 내에서 여러 개의 리액트 버전이 존재한다면, 이벤트 핸들러가 최상단에 붙게 될 것이다. 이는 `e.stopPropagation()`을 어기게 된다. 만약 nested tree에서 이벤트에 대해 전파를 중지하더라도, 바깥 트리에서는 계속해서 이벤트를 받게 된다. 이는 리액트 내부에서 서로다른 버전의 tree를 갖는 것을 어렵게 만든다.

리액트 17부터, 이벤트 핸들러를 더이상 큐먼트의 최상 노드인 `html`에 붙이 지 않는다. 대신, 리액트 트리가 렌더링 되는 DOM Container에 이벤트를 붙이게 된다.

```javascript
const rootNode = document.getElementById('root')
ReactDOM.render(<App />, rootNode)
```

리액트 16 이하에서는, 이벤트 들이 `document.addEventListener()`로 이루어진다. 그러나 17버전 부터는 `rootNode.addEventListener()`로 변경된다.

번역이 거지 같아서 정리

- 특정 노드에 매번 이벤트 리스너를 붙이는 대신, 이벤트 리스너를 부모에게 추가하는 것이 이벤트 위임이다.
- 리액트는 이러한 이벤트 위임을 적극 활용하고 있었으며, 위임의 대상은 `document`였다.
- `document`에서 이벤트가 발생하면, 리액트 이벤트 시스템이 실제로 이벤트가 발생한 컴포넌트를 찾고, 이벤트 버블링으로 상위 컴포넌트에 전달함
- 문제는 여기에서 발생하는데, 네이티브 이벤트는 document 까지 이벤트가 버블링됨 (당연한거 아님?)
- 만약 한 페이지에 여러가지 리액트 버전이 존재한다면, 현재 구조상 모든 이벤트 들이 document에 이벤트를 위임할 것이다.
- 만약 이벤트가 발생한 컴포넌트를 찾아서, 이벤트 전파를 중단하더라도 (`stopPropagation`) 앞서 설명한 것처럼 네이티브 이벤트는 document까지 알아서 버블링이 될 것이기 때문에, 사이드 이펙트가 발생할 수 있다.

[추가 사례 분석](https://github.com/facebook/react/pull/8117)

- atom에서는 여러개 리액트 인스턴스를 생성한뒤, 한개의 앱에서 활용하고 있었다.
- 그러나 두개의 리액트 트리가 nested되어 있는 상태에서는 `e.stopPropagation`이 잘 동작하지 않는 문제가 있었다.
- 그 이유는 두개의 이벤트 리스너가 각각의 트리에 존재했고, 따라서 이들이 각각 전파가 취소되지 않는 문제가 있었다.
  - React version A로 돌아가는 `OuterComponent`와 서로 다른 버전으로 돌아가는 `InnerComponent`가 존재한다고 가정해보자.
  - `InnerComponent`는 이벤트 리스너를 inner tree의 최상단에 이벤트를 부착하려 할 것이고, `OuterComponent`는 해당 컴포넌트의 최상단에 붙이려고 할 것이다.
  - `InnerComponent`에서 클릭이 발생하면, 이 내부버전의 리액트가 트리 더 깊숙히 있기 때문에 이벤트에 대해서 먼저 알아 차릴 것이다.
  - 그리고 이는 `InnerComponent`의 이벤트를 발생시킬 것이고, 따라서 리액트는 `e.stopPropagation()`을 발생시킨다.
  - 이벤트 전파가 중단 되었으므로, 외부버전의 리액트에서는 이를 알아챌 수 없다.
- 이러한 문제를 `html`이 아닌 컴포넌트가 최초에 렌더링되는 `dom`노드에 이벤트를 붙이면서 해결할 수 있음.
- 서로 다른 리액트 버전 (=서로 다른 리액트 인스턴스)을 가지고 있다 하더라도, 이벤트가 부착되는 element가 각각 다르기 때문에 이러한 문제에서 자유로울 수 있음.

요약

- 서로다른 리액트 버전이 페이지 내에서 존재하는 경우 이벤트가 발생했을 시, 리액트에서 일어나는 버블링과 `stopPropagation`때문에 일부 이벤트 실행 여부를 알아채지 못할 수 있음.

![React 17 event delegation](https://reactjs.org/static/bb4b10114882a50090b8ff61b3c4d0fd/1e088/react_17_delegation.png)

이러한 변화로 인해, 한버전에 의해 관리되는 리액트 트리 내부에 서로 다른 리액트 버전을 관리하는 것이 안전해졌다. 이를 위해 두 버전이 모두 최소 리액트 17 버전 이상이어야 한다.

이는 리액트가 다른 기술과 사용하는 것을 더욱 용이하게 한다. 만약 외부에 jQuery가 존재하고, 내부에는 리액트가 존재한다면 이제 예상대로 이벤트 전파를 jQuery단까지 막을 수 있다.

이 변화로 인해, 코드에 몇 가지 변화가 필요할 수 있다. 예를 들어, DOM에 `document.addEventListener`를 활용하여 수동으로 이벤트를 붙여서 리액트의 모든 이벤트를 감지하는 코드가 존재할 수 있다. 리액트 16버전 에서는 이러한 코드가 가능했지만, 리액트 17 부터는 전파가 막히게 되므로 `document`에서도 이벤트가 발생하는지 알 수 없다.

```javascript
document.addEventListener('click', function () {
  // This custom handler will no longer receive clicks
  // from React components that called e.stopPropagation()
})
```

위와 같은 코드는 이제 , `capture: true`를 추가해야 한다.

```javascript
document.addEventListener(
  'click',
  function () {
    // Now this event handler uses the capture phase,
    // so it receives *all* click events below!
  },
  { capture: true },
)
```

결과적으로, 리액트 17의 이벤트 전파가 실제 DOM과 비슷해졌다고 볼 수 있다.

## 기타 Breaking Changes

### 브라우저 최적화

- `onScroll` 관련 이벤트 버블링을 제거하여, 네이티브 `onScroll` 이벤트가 버블링 되지 않는 것과 마찬가지로 동일하게 작동하도록 한다.
- `onFocus` `onBlur`가 네이티브 이벤트인 `focusin` `focusout`을 이용하도록 변경 (이 변경은 실제 버블링에 영향을 미치지 않는다. 리액트에서는 항상 `onFocus`이벤트는 버블링 되고, 리액트 17에서도 마찬가지 일 것이다.)
- Capture phase event (`onClickCapture`)가 실제 브라우저 리스너를 사용하도록 변경

### No Event Pooling

이벤트 풀링이 제거된다. 리액트는 오래된 브라우저의 성능 향상을 위해서 서로 다른 이벤트 사이에서 이벤트 객체를 재사용하고, 모든 이벤트 필드를 null로 설정해두었다. 리액트 16 및 이전 버전에서는 `e.persist()`를 호출하여 이벤트를 적절히 사용하거나, 필요한 속성을 미리 읽어와야 했다.

```jsx
function handleChange(e) {
  setData((data) => ({
    ...data,
    // 리애트 16버전에서는 에러가 났다.
    text: e.target.value,
  }))
}
```

이제 리액트 17에서 부터는 예상처럼 동작한다. 이벤트 풀링 최적화가 완전히 삭제 되었기 때문에, event 필드를 언제든지 원할때 마다 읽어올 수 있다.

사실 breaking changes라고는 했지만, 페이스북에서는 어떠한 문제점도 찾지 못했다. 리액트에 `e.persist()`가 존재하긴 하지만, 실제로는 아무런 동작을 하지 않는다는 것을 알아두길 바란다.

### Effect Cleanup Timing

`useEffect` 라이프 사이클 메서드의 Cleanup 타이밍을 일관되게 동작하도록 만들고 있다.

```javascript
useEffect(() => {
  // effect
  return () => {
    // cleanup
  }
}
```

대부분의 경우 스크린 업데이트를 지연시킬 필요가 없으므로, `useEffect` cleanup은 변경사항이 스크린에 반영된 직후 비동기적으로 작동하도록 변경되었다. (스크린 엽데이트를 지연시켜야 하는 경우 `useLayoutEffect`)

기존에 `useEffect` cleanup은 16버전에서는 동기적으로 실행하기 위해 사용되었다. `componentWillUnMount`와 유사하게, 탭 변경과 같은 큰 사이즈의 페이지 전환에서 성능 저하를 유발한다.

이 변경사항 이후, 컴포넌트가 언마운트 되면 화면이 업데이트 된후 `cleanup`이 실행된다.

또한, 돔 트리에 위치한 순서와 같은 순서로 실행되도록 보장한다.

그러나 위의 변화로 인해 아래와 같은 코드에서 에러가 나는 경우가 있다.

```javascript
useEffect(() => {
  someRef.current.someSetupMethod()
  return () => {
    someRef.current.someCleanupMethod()
  }
})
```

`someRef.current` 는 mutable 하기 때문에, cleanup 함수가 실행되는 순간에 null 이 될 가능성이 있다. 따라서 아래와 같이 고쳐줘야 한다.

```javascript
useEffect(() => {
  const instance = someRef.current
  instance.someSetupMethod()
  return () => {
    instance.someCleanupMethod()
  }
})
```

### undefined를 return 할 경우 일관되게 에러 발생

16버전 이하에서는, 모든 컴포넌트에서 undefined를 리턴할 경우 항상 에러를 발생했다. 하지만 코딩 실수로 인해, `forwardRef` `memo`컴포넌트 에서는 이러한 에러 처리가 누락되어 있었는데, 이제 부터 에러처리가 추가되었다.

```javascript
let Button = forwardRef(() => {
  // We forgot to write return, so this component returns undefined.
  // React 17 surfaces this as an error instead of ignoring it.
  ;<button />
})

let Button = memo(() => {
  // We forgot to write return, so this component returns undefined.
  // React 17 surfaces this as an error instead of ignoring it.
  ;<button />
})
```

렌더링을 아무것도 하지 않기 위해서는, null을 리턴하면 된다.

### Native Component Stacks

브라우저에서 에러 발생시, 자바스크립트 함수이름과 해당하는 위치를 추적하여 에러 메시지에서 보여줬지만, javascript stack이 리액트 트리 구조를 파악하고 진단하기에 충분하지 않았다. 특히 리액트는 소스코드에서 함수가 어디 선언되있는지 모르기 때문에, 콘솔에서 에러를 클릭해서 살펴볼 수 없었다. 또한, 프로덕션 모드에서 더욱 쓸모가 없었다. 일반적인 자바스크립트 스택이 소스맵과 함께 함수명을 복구할 수 있었던 반면, 리액트 스택은 번들 사이즈(에러를 안볼 것인지) 와 프로덕션 스택 (에러를 볼 것인지) 사이에서 선택을 해야 했다.

이를 해결하기 위해, 새로운 메커니즘을 사용하여 component stacks를 생성한다. 이를 통해 프로덕션 환경에서도 리액트 컴포넌트 스택을 추적할 수 있다.

### Private Exports 삭제

- React Native for Web에서 사용하던 private exports를 삭제하였다.
- `ReactTestUtils.SimulateNative` 헬퍼 메소드를 삭제하였다.


리액트 17.0 새로운 기능은 추가되지 않을 예정. 점진적 업그레이드 추가, 이벤트 위임 방식 변경이 주요 변경 내용인 것 같네용.

리액트 v17.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 베타 당첨 및 후기

# Github action

## Github action 은 무엇인가?

github actions은 사용자 정의 소프트웨어 개발 라이프 사이클 워크 플로우를 github 레파지토리에 직접 만들수 있도록 도와주는 도구다.

> GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository.

github actions을 활용하여 코드를 저장하고 협업하는 공간에서 동시에 소프트웨어 개발 워크 플로우를 자동화 할 수 있다.

## 핵심 개념

- action: 작업을 생성하기 위한 단계로, 개별 step을 결합한 단위다. 액션은 워크 플로우 블록을 만드는 가장 작은 포터블 단위다. 직접 만들거나, 깃헙 커뮤니티에 공개되어 있는 것을 쓰거나, 퍼플릭 액션을 커스터마이징해서 쓸 수 있다. 워크플로우에서 액션을 사용하기 위해서는, step이 포함되어 있어야 한다.
- artifact: 코드를 빌드하거나 테스트할 때 만들어지는 파일들을 의미한다. 예를 들어, 아티팩트는 바이너리나 패키지 파일, 테스트 결과, 로그 파일, 스크린 샷등을 포함할 수 있다. 아티팩트는 생성된 워크플로우와 연결되며, 다른작업에서 사용하거나 배포에 이용할 수 있다.
- Continuous integration (CI): 소프트웨어 개발 관습상 공유하고 있는 레파지토리에 종종 작은 단위의 코드로 기여한다. 깃헙 액션을 사용하면, 사용자정의 CI 워크 플로우를 만들어서 빌드와 코드 테스트를 자동화 할 수 있다. 저장소에서, 워크 플로우에 있는 각 액션을 활용하여 코드 변화, 로그 등을 확인할 수 있다. CI는 코드 변화에 따른 버그 등을 빠르게 감지할 수 있다.
- Continuous deployment (CD): 새로 만든 코드가 CI 테스트를 통화가면, 코드는 자동으로 프로덕션에 배포 될 수 있다. 깃헙 액션을 활용하면, 사용자정의 CD 워크플로우를 만들어 클라우드, self-hosted 서비스 또는 플랫폼 등등에 자동으로 배포할 수 있다. CD는 배포 과정과 테스트를 자동화하여 개발자의 시간을 절약해주며, 안정적인 코드 변화를 고객에게 제공할 수 있다.
- Event: 워크플로우 실행이 트리거하는 특정 활동을 의미한다. 예를 들어, 액티비티는 누군가 깃헙 저장소에 코드를 푸시하거나 이슈를 만들거나, PR을 만들 때 발생할 수 있다. 또한 레파지토리에 웹훅을 연결하여 외부 이벤트와 연결 할 수도 있다.
- Github-hosted runner: 깃헙은 리눅스, 윈도우, 맥OS 러너를 호스팅한다. 잡은 완전히 새로운 가상 환경에서 실행되는데, 이 가상환경에는 일반적으로 사용되는 소프트웨어 들이 설치되어 있다. 깃헙은 github-hosted runner의 유지보수 및 업그레이드를 담당하며, 사용자가 임의로 커스터마이징 할 수는 없다.
- Job: 같은 러너에서 실행되는 일련의 단계. 워크플로 파일에서 작업을 실행하는 방법에 대한 규칙을 정의할 수 있다. 작업 (Job)은 이전 작업의 상태에 따라 동시에 병렬로 실행하거나, 순차적으로 실행할 수 있다. 예를 들어 워크플로는 빌드 작업의 상태에 따라 테스트 작업이 달라지는 빌드 및 테스트 작업 두개를 순차적으로 실행할 수 있다. 예를 들어 빌드 작업이 실패하면, 테스트 작업은 수행되지 않을 것이다. github 호스트 러너의 경우 워크플로우의 각 작업은 가상 환경의 새로운 인스턴스에서 실행된다.
- Runner: Github actions runner 애플리케이션이 설치된 모든 시스템. Github이 만든 runner를 사용하거나, 직접 만든 runner를 사용해도 된다. runner는 실행 가능한 작업을 기다린다. runner가 작업을 선택하면, 작업의 액션을 실행하고, 진행상황을 보고하며, 로그를 남기고, 마지막 결과를 깃헙에 리턴한다. 러너는 한번에 하나의 작업만 실행할 수 있다.
- Self-hosted runner: 사용자가 관리하고 유지하는 self-hosted runner 애플리케이션이 설치되어 있는 머신. 이는 깃헙이 제공하는 러너에 비해 더 많은 관리 포인트를 요구한다. 이를 활용하면 작업이 실행될 하드웨어를 커스터마이징 할 수 있다.
- Step: 명령어와 액션을 실행하는 개별 태스크. 작업은 한개 이상의 step으로 이루어져 있다. 한 작업내에서 각각의 step은 같은 러너안에서 실행되며, 파일시스템을 활용하여 작업으에 필요한 정보를 공유할 수 있다.
- Virtual Environment: Github hosted runner의 가상환경에는 가상 머신 설정, 운영채제, 소프트웨어 등이 포함되어 있다.
- Workflow: 사용자가 레파지토리에서 직접 빌드, 테스트, 패키지, 릴리즈, 배포 등을 할 수 있는 자동화 프로세스를 의미한다. 워크플로우는 한개이상의 잡으로 이루어져 있고, 스케쥴링되거나 특정 이벤트에 의해 실행 될 수 있다.
- Workflow file: 하나이상의 작업에 대한 워크플로우 설정이 들어 있는 YAML 파일. 이 파일은 루트 디렉토리의 `.github/workflows` 폴더에 있어야 한다.
- Workflow run: 미리 설정한 이벤트에 의해 실행된 워크플로우 인스턴스. 여기에서 작업, 액션, 로그, 각 워크플로우의 실행항태를 볼 수 있다.

## 워크플로우 파일 살펴보기

위에서 언급했던 것처럼, 이 파일은 `./github/workflows`에 정의 되어 있어야 한다.

```yaml
name: Greet Everyone
# 이 워크플로우는 코드가 푸쉬되면 발동한다.
on: [push]

jobs:
  build:
    # 작업 명칭
    name: Greeting
    # 이 작업은 우분투에서 실행된다.
    runs-on: ubuntu-latest
    steps:
      # 이 작업은 hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action 의 예제다.
      - name: Hello world
        uses: actions/hello-world-javascript-action@v1
        with:
          who-to-greet: 'Mona the Octocat'
        id: hello
      # 여기에서는 이전 스텝에서 부터 얼마나 걸렸는지를 나타낸다.
      - name: Echo the greeting's time
        run: echo 'The time was ${{ steps.hello.outputs.time }}.'
```

## check-out action 활용하기

워크플로우에서 사용할 수 있는 스탠다드 액션 중에, checkout action은 아래와 같은 액션이 있다면 반드시 이전에 실행되어야 한다.

- 저장소 코드를 빌드하거나, 세트스하거나, CI에 활용하기 위하여 저장소 코드의 사본이 필요한 경우
- 워크플로우에 동일하나 저장소에 정의된 작업이 하나 이상 있을 경우

checkout-cation을 사용하기 위해서는, 다음 스텝을 포함하면 된다.

```
- uses: actions/checkout@v2
```

## 워크플로우의 작업 유형을 선택하기

프로젝트의 요구사항에 맞추어 사용할 수 있는 두가지 유형의 액션이 존재한다.

- Docker container 액션
- 자바스크립트 액션

액션을 선택하는데 앞서서 이미 공개 저장소나 도커 허브에 나와 있는 다양한 액션을 살펴보기를 권장한다.

## Nodejs CI 예제

```yaml
name: Node.js CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    # 어떤 노드버전을 사용할지 나타낸다. x는 해당 버전의 가장 최신버전을 의미한다. (wildcard)
    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          # strategy.matrix를 지정하지 않고, 단일 노드버전을 명시하여 하나만 설치할 수도 있다.
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm run build --if-present
      - run: npm test
        env:
          CI: true
```

### 디펜던시 캐싱하기

유니크 키를 활용하여, 현재 디펜던시를 캐싱하고 `cache` 액션을 추가하여 이 캐싱한 디펜던시를 재 활용할 수 있다.

```yaml
steps:
  - uses: actions/checkout@v2
  - name: Use Node.js
    uses: actions/setup-node@v1
    with:
      node-version: '12.x'
  - name: Cache Node.js modules
    uses: actions/cache@v2
    with:
      # npm cache files are stored in `~/.npm` on Linux/macOS
      path: ~/.npm
      # 캐시키
      key: ${{ runner.OS }}-node-${{ hashFiles('**/package-lock.json') }}
      # 캐시키로 찾지 못했을 경우 다시 시도해볼 키
      restore-keys: |
        ${{ runner.OS }}-node-
        ${{ runner.OS }}-
  - name: Install dependencies
    run: npm ci
```


# Github action ## Github action 은 무엇인가?  github actions은 사용자 정의 소프트웨어 개발 라이프 사이클 워크 플로우를 github 레파지토리에 직접 만들수 있도록 도와주는 도구다.  > GitHub Actions enables you to create custom software development life c...

Github 1

github workflow로 lighthouse ci 추가하기

Github action cron이 제시간에 실행되지 않는 문제

리액트 v17.0 살펴보기

Github Code Spaces 베타 당첨 및 후기

Github actions 요약