윤민상 블로그

개발환경 적용은 끝났다. 테스트코드나 ci cd까지 추가하는 건 너무 광범위하다고 생각해서 다루지 않을려고 했다. 그런데 storybook을 적용하면서 몇가지 문제점이 생겨서 적용방법만 소개해보려고 한다. 스토리북 설치하기 다음 명령어로 스토리북을 설치하자. 참고로 yarn이아니라서 그냥 레포에 직접 들어가서 명령어를 입력하면 된다. npx는 yarn 환경이라면 yarn으로 알아서 설치해준다. npx sb init --builder @storybook/builder-vite 이게 끝이면 내가 글을 쓰지 않았다. yarn story명령어로 스토리북을 실행하면 import를 할 수 없다는 에러가 발생한다. 해당 라이브러리를 찾아보니 실제로 설치되지 않은 라이브러리다. 아마 내부에서 사용되는 것 같은데... ..

추가적인 문제점 찾아보기 yarn berry로 npm의 고질적인 문제점을 해결하고 monorepo로 재사용성을 높였다. 이제 아무런 문제가 없을까?? 프론트개발자는 항상 문제를 찾아야한다. 주어진 환경에 만족하지 않고 불편함을 느끼고 해결할 방법을 찾아야한다. 내가 느낀 불편한점은 웹팩이다. 웹팩은 너무 느리다. 빌드시간도 느리고 서버 구동시간도 느리다. 웹팩은 분명히 많은 사람들이 사용하고 레퍼런스도 많다. 하지만 문제점도 분명하다. 너무 느리다. 불필요한 플러그인을 제거하고 terserplugin을 적용하거나 gzip압축을 하고 캐시를 적용해도 본질적인 문제는 해결되지 않는다. 웹팩의 문제점 그러면 웹팩이 왜 느릴까?? 사실 프론트엔드의 발전과정을 이해해야한다. 너무 자세히 말하면 주제가 달라지기 때..

커져가는 프로젝트의 문제점 인지하기 저번 글에서 yarn berry에 대해서 학습했다. 기존 npm에 대한 숙제 하나는 끝낸 셈이다. 그런데 다른 문제가 발생했다. 개발자 대부분은 회사를 다닌다. 그리고 대부분의 회사에서는 만들고 끝이 아니라 끊임없이 유지보수하고 기능을 추가한다. 처음에는 가벼운 프로젝트라고 할지라도 시간이 지남에 따라 엄청 거대해진다. 전혀 다른 프로젝트라면 새롭게 프로젝트를 시작하면 되겠지만 기존 프로젝트의 디자인 시스템이나 유틸함수, 상수등을 공유해야될 경우가 있다. 이걸 npm으로 배포해서 여러프로젝트에서 install하는 형식도 있겠지만 관리가 너무 힘들다. 컴포넌트만 하더라도 매일매일 변경되는데 이걸 매번 배포하고 업데이트를 할 생각을 하면 벌써 머리가 아프다. 이럴때 mon..

npm과 yarn 프론트엔드 혹은 nodejs개발자라면 npm이라는 말을 다들 들어보고 사용해봤을 것이다. npm은 Node Package Manager의 약자이다. 즉 node기반의 모든 패키지들을 관리하는 툴이다. 그리고 npm과 더불어서 yarn이라는 것도 많이 사용된다. yarn은 npm 구조에 의존하고 있으며 페이스북에서 만들었고 속도나 보안측면에서 조금 장점이 있다. 그대신 디스크 용량을 조금 더 잡아먹는다고 한다. 사실상 명령어가 조금 다른것을 제외하고 눈에 띄게 차이가 나지는 않는것같다. 애초에 yarn은 npm에 의존하고 있기도 하고 차이가 심하다면 다들 yarn을 사용할텐데 그래도 아직까지는 npm 이용자 수가 더 많다. 문제점 인지하기 npm이나 yarn을 사용하면 큰 문제없이 패키지..

svg를 string으로 불러오기 ~~.d.ts에 아래와 같이 string으로 불러오고 이미지 태그안에 src로 넣으면 svg를 사용할 수 있다. declare module '*.svg' { const value: string; export = value; // } 그런데 svg태그 자체가 필요한 경우가 있다. 예를 들어 fill을 한다던가... 그럴때는 조금 설정이 필요하다. svg 자체 태그를 불러오기 먼저 웹팩 간단한 웹팩 설정이 필요하다. yarn add -D @svgr/webpack { test: /\.svg$/, use: ['@svgr/webpack'], }, 그리고 d.ts를 아래와 같이 변경해야 한다. ~~.d.ts declare module '*.svg'; 마지막으로 불러올 때 다음과 같..

배경 예전부터 이름은 들어서 알고 있었다. 최근에 밤에 이것저것 찾아보다가 급 관심을 가지게 되었는데 찾아보니 진짜 혁명이였다. 서버사이드 렌더링에 코드 스플리팅, lazy loading, 이미지 최적화까지 전부 다 지원한다고 한다. 하나하나가 굉장히 귀찮으면서도 꼭 해야만 하는 작업들인데 이걸 전부다 그냥 해준다니 진짜 말도안된다... 그래서 새벽에 블로그를 잠깐 찾아보다가 자기전에 한시간동안 유튜브에서 강의 영상까지 봤다. 어떻게 시작할건데 리액트를 처음 사용할 때는 cra를 사용한다. 나는 지금은 직접 설정하지만 처음에 시작할 때는 설정하기가 쉽지 않다. 그래서 일단은 create next app을 이용하려고 한다. npx create-next-app@latest --typescript yarn c..

배경 테스트에 최근에 관심이 생겨서 백엔드는 해봤는데 프론트 개발자가 프론트 테스트를 제대로 해보지 않았다. 그래서 차근차근 조금씩 학습할 예정이다. 프론트엔드에서 테스트가 필요한 이유 백엔드는 당연히 테스트가 필요하다. db에 접근하기 때문에 실수가 나오면 안되고 ui를 보고 직접 테스트하는게 불가능하기 때문에 어차피 수동으로 테스트를 해볼려면 일일히 postman을 이용해서 하나하나 테스트해봐야 한다. 그리고 많은 쿼리가 들어오면 서버가 터지기도 하기 때문에 진짜 필수다. 그런데 프론트에서도 필요할까??? 사실 간단한 프로젝트에서는 필요하지 않다. 그냥 버튼 몇 번 클릭해보면 눈으로 확인 가능하니 말이다. 하지만 프로젝트 규모가 커지고 실제로 배포해서 사용자가 있는 서비스에서는 사소한 오류라도 나와서..

배경 저번에 글을 한번 올렸었는데 설정이 조금 바뀐것들이 있어서 다시 글을 쓴다. 청크라던가 코드스플리팅은 아직 적용하지 않았다. 너무 어렵다. 진짜... 쉬운게없네... 간단하게 코드와 설명만 적겠다. 개념은 저번글을 참고하면 된다. 버전 package.json "dependencies": { "@babel/cli": "^7.14.8", "@babel/core": "^7.15.0", "@babel/preset-env": "^7.15.0", "babel-cli": "^6.26.0", "babel-loader": "^8.2.2", "compression-webpack-plugin": "^9.0.0", "core-js-pure": "^3.16.1", "css-loader": "^6.2.0", "css-min..