fe conf

FECONF 2022

트랙 A 다시보기
트랙 B 다시보기

2022.10.08 fe 컨퍼런스에 참여했다.
생각보다 많은 프론트엔드 개발자가 있어서 진짜 놀랐고 다시금 난 아직 햇병아리라는걸 실감했다..
아래 내용은 다녀오고 난 후, 다시 youtube를 보면서 간략하게 내용을 정리해봤다.

디자인 시스템, 형태를 넘어서

디자인 시스템의 중요성

디자인 시스템에 대한 개념 없이, 위와같은 <Selectbox /> 를 구성하려고 한다면 위처럼 구현가능하다.

1. 계속해서 필요한 기능을 props로 붙이기 → 복잡성 증가
2. 기능마다 다른 컴포넌트 만들기 → 파편화 증가

디자인시스템의 책임과 기대가 불분명해 졌을 때, 위와같은 병목 현상이 발생할 수 있다.

디자인 시스템의 정의

1. 형태 - 디자인 스펙
2. 기능 - 컴포넌트의 동작
3. 접근성 - 요소에 대한 힌트
4. 커스텀 - 형태나 기능들에 대한 기능 커스텀

형태를 가지지 않는 라이브러리(B)

Zag - Rapidly build UI components without sweating over the logic. - Zag

React Aria

동작을 정의하는 훅을 정의해 형태를 정의하지 않음

linear 디자인 시스템

원칙

1. 기능과 형태는 독립적 - 디자인과 동작은 다르다
   • 최상위에서 context를 관리
   • 하위에서 trigger를 받아서 동작
2. 기본동작을 보장 - 반복성 ⬇️  기본동작이 아닌 것은 정의하지 않는다
3. 최소한의 제약만 가진다

일백개 패키지 모노레포 우아하게 운영하기

https://github.com/toss/slash
이번 세션이 끝나고 공개한 토스에서 사용중인 라이브러리

• 모노레포란

  https://d2.naver.com/helloworld/0923884

  버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 사용되는 SW 개발 전략

  모듈은 분리되어 독자적인 프로젝트로 존재하지만 저장소는 같은 곳을 사용한다.

  • 모노레포가 적절한 상황
    • 유사한 제품의 집합
    • 여러 프로젝트의 변화를 한눈에 파악해야 할 때
    • 호스트 애플리케이션을 플러그인 등으로 확장할 때
    • 공통 기능을 재사용하는 관련된 프로젝트의 집합
    • 유사한 DevOps로 구성된 프로젝트의 집합
    • 멀티레포의 단점을 보완

모노레포를 언제 사용해야 할까요?

• 멀티레포의 문제점을 보완하고 싶을 때
  • 새 프로젝트 생성 비용이 큼
  • 프로젝트간 코드 공유의 어려움
  • DE(개발자 경험)이 일관적이지 않음 등..

모던 모노레포 툴에서 제공하는 기능

1. 속도
   1. Local computation caching - 같은 레포 같은 작업 X
   2. Local task orchestration - 자동화된 설정, 병렬처리 여부
   3. Distributed computation caching - 원격 캐싱 및 저장
   4. Detecting affected projects/packages - 프로젝트 변경 감지, 영향 받는 프로젝트에만 작업 수행
2. 관리
   1. Source code sharing - 프로젝트간 코드 공유
   2. code generation - 코드 생성 쉽게 도와줌
   3. Project constraints and visibility - 의존성 관계 설정

라이브러리 모노레포

라이브러리 모노레포 vs 서비스 모노레포

	커밋 수	배포	영향범위 / 커밋
라이브러리 모노레포	많음	NPM	큼
서비스 모노레포	적음	내부 인프라	작음

특징

1. 의존성 관리

   • 유령 의존성(Phantom Dependency)

     중복해서 설치되는 모듈을 피하기위해 호이스팅 기법을 사용하게 되는데, 이로인해 dependency로 명시되지 않은 라이브러리를 불러올 수 있음

     이는 런타임 에러로 이어질 수 있음
     

   • Yarn berry + PnP

     의존성 라이브러리는 cache 폴더에 압축파일 형태로 정리되고, .pnp.cjs를 통해 엄격하게 관리되므로 명시되어 있지 않은 의존성 라이브러리를 사용할 수 없으며 이에따라 유령 의존성 문제가 해결됨

     → zero install

     → 빠른 의존성 검색
     

   • Peer Dependency
     

     패키지를 사용하는 곳에서 제공해야하는 dependency (위 사진에서 P의 번들에 하나의 B만 포함됨)

     • 싱글턴으로 존재해야하는 패키지일 때 사용하면 좋다

     • 문제점

       • Peer Dependency는 전파된다. 아래에서 사용하지 않는 P를 추가해야하는 것을 볼 수 있다. 이는 복잡성을 증가시킨다.
         
       • 위의 복잡성으로 잠재적 런타임 에러 발생 위험이 있다.

2. 버전 관리

   • Semver를 잘 지키자
     

     • 버전 number가 어떻게 할당되고 유지되어야하는지에 대한 규칙

   • Toss에서는 lerna version을 사용중

3. 코드 품질 관리

   • RFC
     
     PR을 올리기 전 아이디어만으로 추가나 기여하고 싶은 부분을 올림
     
   • PR

4. 문서화

   • JSDoc
   • Docusaurus

내 import 문이 그렇게 이상했나요?

CommonJS vs ESM

	CommonJS	ECMAScript Modules (ESM)
특징	require로 라이브러리를 가져옴
(ts, babel 사용시 자동으로 require로 변환됨)	함수 import, export
	동기적으로 동작	Top-level await - 비동기적으로 동작
	파일 단위의 개발	재할당 X, 정적분석 가능
		Node.js 뿐만 아니라 브라우저, Deno 등에서도 사용 가능
문제점	표준이 아니기때문에 Node.js가 아닌 환경에서 사용 불가능
	정적 분석 어려움 (조건 호출 가능)
	비동기 모듈 정의 불가능
	require 함수 재정의 가능

• 최근에는 ESM을 사용하는 추세
  

ESM은 비동기적으로 동작하므로 CommonJS로 마이그레이션하기 용이하다

Node.js에서의 ESM 규칙

package.json

ESM

{
	...
	"type": "module",
	...
}

Commonjs (기본값)

{
	...
	"type": "commonjs",
	...
}

.js 파일이 가장 가까운 package.json 설정을 따른다

.cjs, .mjs

.cjs는 항상 CommonJS, .mjs는 항상 ESM 파일이다. 해당 확장자를 이용해 일부 파일만 사용 가능하다.

ESM Migration

Migration이 어려운 이유

1. 가짜 ESM (commonJS로 바껴서 사용됨)

2. 성숙하지 않은 생태계 (아래 서비스는 아직ESM 불가)

   1. Typescript
   2. Next.js - subpath import 문제 (정확한 확장자 필요)
      2022/10월 기준 Export field를 사용하고 있지 않음
      
   3. jest, tsnode, yarn pnp → commonJs 사용

ESM으로 migration하기

import { Component } from './MyComponent.js'

• ESM import 는 정확한 확장자를 필요로 한다. → Deno를 만든 이유 중 하나
• CommonJS는 확장자 없이 사용이 가능한데, 이때 정확한 확장자를 찾기 위한 시간이 걸린다.

후기

정말 신기했던 WebGL로 만든 추천 웹

일단, 전부터 궁금해했던 monorepo, yarn, ESM등에 대한 얘기를 자세하게 들을 수 있어서 뜻깊은 시간이였다.
사실 실제 참석했을때는 프론트엔드 DDD를 만나다 와 상태관리, 이 전쟁을 끝내러 왔다 세션도 들었는데...... 이해하지 못해서 차마 블로그에 적을 수가 없었다.. 😢😢😢😢
언젠가 실제 현업에 적용할 수 있기를, 나도 저렇게 발표할 수 있기를 간절히 바라며 오늘 글을 마무리한다!