이 작업은 굉장히 오래 걸렸다. 작업 자체가 어렵진 않았는데, 처리할 일이 많아서 시간을 연속적으로 투자할 수 없었는데, 그래서 오래 걸린 것 같다. 시간 투자가 힘들어서 PR을 쪼갰는데, 결과적으로 4개로 쪼갰다.

PR 1: 파서

• PR #6981

Stage 3 데코레이터 제안엔 Auto Accessor라는 게 같이 들어있다. 그것 때문에 AST를 변경해야해서 PR을 분리했다. AST를 변경하면 Wasm 플러그인들이 꺠지기 때문에, PR을 분리하는 게 편하다.

파서 변경사항은 인식해야하는 키워드가 명확해서 어렵지 않았다. AST 변경 또한 어렵지 않았다. API 결정하는 걸 별로 안 좋아하는데, 이건 뭐... 클래스 프로퍼티에 키워드 하나 추가한 수준이더라. 근데 private 하고 public을 둘 다 지원해서 타입이 깔끔하지 않아졌고, 그게 조금 마음에 안 들었다.

PR 2: Stage 3 데코레이터

• PR #6950

처음엔 Auto Accessor 까지 한 PR에서 처리할 생각이었다. 그런데 다른 할 일도 많고, 논리적으로도 쪼개는 게 맞는 것 같아서 Auto Accessor 지원을 다른 PR로 분리하기로 했다.

어려웠다고 하긴 좀 애매하다. 순수 난이도가 높진 않았다. 그런데 내가 원본 코드 보는 것을 싫어해서 순수 TDD를 했는데, 그게 시간을 많이 먹었고, babel이 뱉은 코드를 읽는 게 어려웠다.

멤버에 대한 데코레이터는 패턴을 찾는 게 어렵지 않았지만, 클래스 데코레이터 작업할 떄 조금 해맸다.

@dec
class Foo {
  static foo = new Foo();
}

위와 같은 아주 간단해보이는 입력값이

let _Foo;
_dec = dec;
new ((() => {
  class Foo {}
  [_Foo, _initClass] = _applyDecs(Foo, [], [_dec]).c;
})(),
class extends _identity {
  constructor() {
    (super(_Foo), _defineProperty(this, "foo", new _Foo())), _initClass();
  }
})();

로 컴파일되더라. 지금 와서 보면 구조가 매우 잘못되어있었지만 이 작업까지 했을 때는 그런 거 몰랐고 테스트 케이스들이 다 통과하길래 머지하고 배포했다.

PR 3: Auto Accessor 부분적 지원

• PR #7364

PR 숫자를 보고 눈치챘을 수도 있는데, 2번 PR과 텀이 꽤나 크다. 그래서 이거 작업 시작할 떄 분리하길 잘했다는 생각을 했다.

이 PR에서는 주로 리팩토링을 했다. 원래 Auto Accessor를 지원하려고 했는데, 구조를 잘못 잡은지라 수정할 게 너무 많아서 PR을 분리하기로 했다. 그래도 데코레티터가 붙어있지 않은 Auto Accessor를 지원하도록 수정하기는 했다.

PR 4: Auto Accessor 완전 지원

• PR #7370

원래 이 PR은 저번주 금요일에 끝낼 계획이었는데, 금요일에 학교 축제하고 친구 생일파티에 가기로 한지라 그날은 휴가 쓰고 주말에 마무리했다.

난이도는 좀 있었다. 이번에도 클래스 레벨 데코레이터가 문제였는데, TDD를 계속 반복하다보니까 패턴이 보이긴하더라. 그래서 잘 구현했다.

---

이 작업은 기록으로 남겨두고 싶었던 것이 그리 많지 않은 관계로 이만 줄이겠다.