얼마전에 새 맥북을 구매하였는데... 기존에 너무 당연하게 쓰고있던 설정들이 안되어있다보니 조금 당황했었습니다.어차피 새 맥북을 살때마다 해야한다면 기록을 남겨두는 게 편리하겠죠 현재 git branch를 간단하게 확인하기git config --global pager.branch falsepager 설정이 켜져있는 경우 git branch로 현재 브랜치 위치를 확인한 뒤 계속 대기하게됩니다.저는 요게 굉장히 불편했어서 다음 설정으로 꺼주는 편입니다. git push시 알아서 origin의 현재 브랜치로 푸시하기git config --global push.default current이것도 간단하게 git push로 적절하게 푸시하고 싶을때 유용합니다. 자주 쓰는 명령어 단축어로 설정하기nano ~/.zsh..
1. 디자인 시스템의 컴포넌트는 어디까지 Primitves 해야할까?디자인 시스템 컴포넌트의 어려움은 광범위하게 참조된다는 것에서 기인하는 것 같다는 생각이 많이 듭니다.너무나도 광범위하게 사용되다보니 작은 css 수정은 물론 컴포넌트의 인터페이스를 교체하는것이 굉장히 큰 이펙트로 영향을 끼치게 된다는 점이 공포입니다.저는 주로 사용성을 위해 디자인 시스템 컴포넌트에 특정 기능이나 css를 기본적으로 박아두는 행위 (w값을 기본값으로 준다거나.. padding에 대한 기본값이 존재한다거나) 같은 짓을 했다가 나중에 특정 사용처에서는 기본값이 존재하면 오히려 안되는 상황에서 진퇴양난에 빠지게되는 경우가 많았던 것 같습니다.그런데 그렇다고해서 Primitves한 컴포넌트의 스타일을 극단적으로 Primitve..
모노레포를 위한 패키지매니저는 제 개인적인 생각이지만 pnpm으로 귀결되고 있다고 생각합니다.npm, yarn은 구조적인 한계가 뚜렷하고 bun은 주목할만하지만 아직 프로덕션에서 사용하기에는 섣부른 감이 있습니다.yarn 2는 PnP 방식이 갖는 태생적인 문제와 자잘하게 떨어지는 DX가 거슬리는 면이 있죠.. 결국 소거법을 하고나면 남는게 pnpm 밖에 없는데 정작 React Native 개발을 하는 경우에는 Pnpm이 골칫거리로 다가옵니다.Pnpm의 핵심 기능인 심볼릭 링크가 RN 생태계와 제대로 호환되지 못하고 있었다는 점 때문인데요RN 0.72 버전부터 심볼릭 링크를 지원한다고는 했지만 순순히 그냥은 동작해주지 않는다는 점과 빈약한 문서로 인해 사실상 못써먹었습니다. 아마 저만 못써먹은 건 아닌 것..
storybook은 일반적으로 chromatic에 배포하는 경우가 많은 것 같습니다.하지만 제 개인적으로는 chromatic 생태계와 대시보드를 한번 더 학습해야하는 비용이 있다보니 스토리북 관리를 하기 싫게 만드는 이유 중 하나였는데요 chromatic 생태계에서 사용할 수 있는 기능들이 필요한 것이 아니라면 사실 storybook 빌드 결과물은 chromatic에 종속적이지 않으니 github pages나 netlify 등 다양한 정적 호스팅 사이트와도 쉽게 결합할 수 있습니다.마찬가지로 vercel과도 원활하게 통합을 수행할 수 있는데요 이번에는 vercel로 스토리북을 배포한 과정을 다뤄보겠습니다. 사실 그냥 배포하면 됩니다만은 저는 모노레포로 패키지를 관리하고 있다보니 이와 관련하여 자잘하게 귀..
최근 turbo-repo를 흥미롭게 보며 학습하고있습니다.yarn workspace 기능만으로 바닥부터 만들어나갈때의 불편함들이 많이 해소된 형태로 api 들이 제공되어서 DX에 매번 놀라고 있는데요그렇다보니 크게 막히는 부분이 있지는 않았지만 조금 헷갈렸던 부분이 있어서 정리해봅니다.큰 내용만 먼저 정의를 해보자면 다음과 같은 내용입니다. tailwindcss를 사용할 때 모노레포 프로젝트라면 configuration을 어디서 어떻게 적용해야하는가?https://turbo.build/repo/docs/guides/tools/storybook Storybook | TurborepoLearn how to use Storybook in a Turborepo.turbo.build turbo repo의 stor..
모노레포는 이미 현대 프론트엔드에서 떼어놓고 이야기할 수 없는 존재가 된 것 같습니다.이제 대부분의 메이저한 도구들의 Docs에서 모노레포에 대한 가이드라인이 작성되어 있는 것을 심심찮게 찾아볼 수 있으며다들 모노레포가 가져다주는 장점에 대한 공감대는 형성되어있는 것 같다고할까요? 그런데 그럼에도 불구하고 모노레포의 지저분한 부분들을 다루는 아티클들은 찾아보기 힘들었습니다.제가 능력이 부족해 못찾은 것일수도 있지만 저같은 경우엔 찾기가 힘들더라구요그러던 중 터보레포가 메이저버전 2를 출시하면서 Docs도 새롭게 개편한 것을 알게되었는데 이 터보레포의 Docs에서 평소 고민하던 부분들에 대한 답을 시원하게 얻어가는 경험을 하게되어서 소개드립니다. 보통 모노레포로 프로젝트를 구성한다고 하면 일반적으로 이러한..
최근 프론트엔드 커뮤니티를 중심으로 Feature-Sliced Design에 대한 관심이 이전에 비해 많아졌다고 느낍니다.저같은 경우에는 클린아키텍처를 프론트엔드에 적절히 적용할 방법을 고민하다가 접하게된 방법론이기도 한데 꽤 마음에 드는 방법론이었어서 개인 프로젝트는 물론 사내 프로젝트도 점차 Feature-Sliced Design을 따르는 형태로 리팩토링한 경험이 있습니다.이렇게 제가 처음 Feature-Sliced Design을 접하고 지금까지 꽤 많은 프로젝트를 Feature-Sliced Desgin을 통해 진행하면서 느꼈던 인사이트들을 공유해보고자 글을 작성해봅니다. Feature-Sliced Design이란?https://feature-sliced.design/docs/branding Bran..
안녕하세요 오늘은 변경에 자유로운 코드를 작성하기라는 주제로 이야기를 해보겠습니다.사실 거의 상식이나 다름없는 느낌으로 많이 알려진 내용이다보니 거창한 척(?) 말하는 것이 조금 민망하기도 합니다어떻게하면 변경에 자유로운 코드를 작성할 수 있을까요?쉽게 생각해봤을 때 우리의 커다란 목적에만 집중할 수 있는 구조를 만들면 우리는 작은 내용들이 바뀌더라도 우리의 커다란 목적으로 향해 가는데에 아무런 영향도 받지 않을 수 있을 것입니다. 그렇다면 어떤 내용이 "작은 내용" 일까요?여러가지 견해가 있을 수 있겠지만 저는 라이브러리, 프레임워크와 같은 외부 코드들은 기본적으로 항상 "작은 내용"이라고 생각하려고 하는 편입니다.채용공고에는 리액트, next.js와 같은 라이브러리, 프레임워크들이 "당연"하다는 듯이..
