Frontend Trend 따라잡기

오프닝

GDG Korea WebTech에대한 소개와 함께 컨퍼런스 진행

Monorepo의 기쁨과 슬픔 / 한근택님

인프런에서 개발중이신 프론트엔드 개발자, 자동화와 문서화에 관심이 많으심

아래의 내용을 주제로 희망편과 절망편 소개해주실 예정

1. 프론트엔드 모노레포(터보레포)
2. 사내 디자인 시스템(체인지 셋) -> 배포 & 버저닝

모노레포

모노레포 도입고민은 누구나 다 하는 그 고민을하심 ㅋㅋ

문화적인 요소를 고려 (out of sight, out of mind를 막고싶었다)

셀마다 레포를 모놀리틱하게 가져가면 관심도가 떨어지게될테니 모노레포를 고려했다는 내용 모든 패키지가가 디자인시스템을 소비하며 shared 패키지도 디자인시스템을 소비하는 레포지토리였다 -> 패키지간의 의존관계

모노레포간의 패키지간의 의존성이 가시적으로 관리되면함 디벨롭 브랜치에 머지가되면 모든 패키지 배포가 되어야함

오늘의 주제 터보레포가 나옴

디자인시스템 패키지가 변경되면 디자인시스템부터.. 쉐어드 패키지부터.. 마지막 패키지까지 관리가 어려워지게된다

터보레포의 파이프라인을 구성하여 패키지의존관계를 작성해주어 빌드관계를 명시해주기 편했음 이미 빌드된 디자인시스템 패키지의 캐시를 사용이 가능하므로 더 빨랐다. 터보레포는 모노레포의 의존성을 자동으로 파악하여 태스크를 병렬로 수행

병렬태스크의 동시성을 제어도 가능했다. 자원사용량과 실행가능한 태스크의 수를 조절이 가능했음

CI/CD 파이프라인에서 바뀐 패키지만 트리깅할수있게 필터 상세 설정이 가능했음 -> 직전커밋에서 변경된 패키지만 빌드되도록 했었다~~ 라고함

--> 이렇게까지만 하면 희망편이고 아래부터는 절망편이다

브랜치전략이 확실하지않으면 혼돈이 시작된다 + tsc lint 의 회초리로 인해 커밋이 안되는경우 + 생각보다 다른 패키지에 관심이 가지게 되지않았다.

셀마다 모노레포를 분리하는것으로 변경하게되었는데 여기서 질문을드렷다.

도입이유에는 셀마다 다른 패키지에대한 관심이 뭉쳐야 관심이 가기에 모노레포를 도입한건데 셀마다 분리하게 되면 이는 도입이유에서 멀어지게 된게 아닌가요?

답변 -> 어떻게보면 맞다. 근데 정량체크를해보앗다. 다른셀의 개발자가 코드리뷰하는 양을 체크해보았고 크지않았다. 그에반해 통일하는 모노레포를 도입해서 얻은 고통을 감내할빠엔 분리하는게 맞다고 생각해서 분리하게되었다고하심

디자인시스템

바뀐 패키지만 배포가 되어야하고 트리셰이킹이 원활하도록 ESM으로 되어야한다.

자동화 -> 개발자가 코드 이외의 부분에는 최대한 신경을 덜쓰게하고싶었다... -> changesSets

해당기능을 사용하니 개발자들은 코드변경 + 리뷰만하기에 개발사이클이 굉장히짧아졌다.

하지만 슬픔도있음

러닝커브 + 깃헙액션에 의존적이며 불친절한면도있었다.

TypeScript v5로 타입서커스 / 강종연님

5.0이 타입스크립트 블로그에 나온내용을 공유해주며 시작하셨다. 타스는 자바스크립트의 타입체킹을 추가한 언어

메이저버전이 올라가면서 당연히 따라오는 성능개선에 짤막하게 설명해주심

const Type parameters

as const를 통해 타입좁히기가 가능해진다~ 해당기능을 사용한 구체적인 타입을 즐겨쓰신다.

5.0에서는 const modifiers를 지원하기 시작했다. -> 찾아보기

supporting multiple configuration

extends 옵션이 string[]으로 변경되었다. -> 컨피그 복수설정이 가능해졌다 우선순위는 낮은 인덱스부터

Enums

초기의 이넘과 2.0이후의 이넘을 비교해주며 좋다좋다했다. -> 근데 문제도 많음

5.0 부터는 계산된 멤버값에 대해서 고유 타입을 생성하여 합집합으로 만듬 -> 타입먼저 생성 vs 계산후 타입생성 -> 이때부터 멤버를 타입으로 참조가 가능

Overhaul -> 고친것들을 명시해주었음 -> 근데 좀 난해한것들이있음 이건 문서로 확인해야할듯함

--moduleResolution bundler

// entry.mjs
import * as utils from './entry'

import * as utils from './entry.mjs'

-> 확장자를 명시하라고했지만 기존의 번들러와 충돌이 많아, 번들러 옵션설정을 하게해주었다...? 좀 이상함ㅋ

export type *

3.8에서는 type을 import, export하는 문법이 도입됨

최적화

최적화된 내용중에 let, const를 var를 사용하여 성능개선한 부분이있다하는데 굉장히 흥미로움(링크)

Next v13 미리보기 / 정준혁님

넥스트써본놈~ 거수 하면서 시작하심

SSR & SSG / File System Routing(pages router) 에 대해 간단하게 설명해주심~

13에서 나온거

• 앱 라우터
• RSC
• streaming
• parral routing

RSC

SSR이랑 무슨 차이냐?

SSR은 서버에서 html 만들고 클라이언트에게 던지고 하이드레이션 작업

RSC는 서버에서 html 만들고 클라이언트에게 던지기만한다. -> 하이드레이션이 필요없다 -> 서버에서만 굴러갈거니까

App router

네이밍 규칙이생김

레이아웃 규칙이 생김 -> 폴더구조를 따라가기에 중첩된 레이아웃을 사용할수있게됨

Group -> 폴더라우팅에 영향을 주지는않지만 관심사를 모을수있을것으로 보임

SSR Streaming

해당기능 사용시 더 작은 청크단위로 쪼개어 클라이언트가 사용이 가능해진다..?

댄의 Suspense SSR React 18을 가져오심 (링크)

SSR와 차이점은 SSR에서 전체페이지를 로딩되는 부분을 유저가 기다려야했지만 스트리밍 SSR은 몰?루

병렬 라우팅

레이아웃에서 분기처리가 가능해진다...?

데이터 페칭

네트워킹