Bit에서 수행할 리팩토링:

  • config api가 너무 concete하고 커플링을 유발하므로 구성을 조화로 위임해야 합니다.

    • 형식의 직렬화 및 역직렬화를 표준화하는 것으로 시작합니다.
  • 지금은 api 파일의 모든 구현을 또는 Bit 확장으로 리팩터링하십시오.

  • 디버그 환경 변수의 이름을 BLUEBIRD_DEBUG에서 DEBUG로 변경하십시오.

  • 외부에서 다시 적용할 수 있도록 Bit에 파일 시스템을 리팩터링합니다.

  • 작업 공간을 통해 Bit 외부의 파일 시스템 및 경로 선택을 통합하고 리팩터링합니다.

  • cli 인프라 재작성 및 교체

    • Ink 또는 다른 것을 사용하여 UI에 대한 구성 요소를 반응합니다.
    • 확장을 통해 stdout 스트리밍을 지원합니다.
    • extensions
    • Promise에 Progress API를 추가하고 모든 것을 Observable에 보고합니다.
    • 모든 것에 대해 json 지원
  • 리팩터링 및 좁은 Scope 공개 API.

  • 점진적으로 리팩토링하고 소비자 API를 새로운 Workspace API로 좁힙니다.

  • "Bit" 모듈에서 비트의 API를 재설계하고 우리의 API로 노출합니다.

  • prettier는 생성자가 어떻게 생겼는지 완전히 깨뜨립니다(모든 프로젝트에 동일한 더 예쁜 것을 정의하고 적용).

  • 구성 요소 ID 모듈에 비트 ID를 리팩터링합니다.

  • 가져온 후 구성 요소 표현을 얻지 못하는 이유는 무엇입니까? 혼란스러운 사용자 경험으로 이어집니다

  • 범위에 대한 그래프 액세스.

  • 어떤 확장을 로드할 것인가? 확장의 지연 로딩은 정말 복잡해질 수 있습니다. 우리는 사용자가 직접 구성한 모든 것을 설치하고 그렇지 않은 것을 지연 설치하고 범위 지정을 사용합니다.

  • 오래 지속되는 캡슐 및 캡슐 cli. 여기에서 제품을 이해하고 CI에 연결하십시오.

  • 구성 요소에 대한 새 파사드를 만들고 비트의 유일한 구성 요소 모델이 되도록 천천히 리팩토링합니다.

  • 프로세스 배포 및 v8 격리(프로세스 v8: 격리)를 사용하여 메모리 사용을 위한 캡슐 작업자를 빌드합니다.

  • 비트의 모든 경로를 절대 경로로 리팩터링합니다.

  • Component 새 API 위에 있는 것이 좋습니다 .

  • 지휘관을 적절한 것으로 교체하십시오(amit).

  • 런타임에 충돌을 피하기 위해 확장을 컨테이너에 포함하는 것을 고려하십시오.

  • 구성 요소 외부의 구성 요소를 리팩토링합니다.

things done: