[개인 프로젝트 ShareLife] SNS 만들기 기획 & 환경 설정 단계

규갓 God Gyu·2024년 8월 9일
프로젝트
0

프로젝트

목록 보기
61/81

유저 플로우

와이어 프레임

로그인

회원가입


생일, 이메일 인증, 이용약관은 보류
만약 디벨롭을 한다면 이메일 인증정도?

메인 페이지

  • 게시글 보이는 페이지
  • 게시글 작성 페이지
  • 게시글 확대 클릭 페이지
  • 검색 페이지(유저 검색)
  • 메시지 페이지(유저와의)
  • 좋아요한 목록
    여기선 고민인게 좋아요 목록일지/친구 목록/ 친구의 활동 알림/ 나를 팔로우한 사람을 알려주는 알림??
    뭐든 데이터 흐름이 쉽진 않아보임
  • 프로필 페이지

이 후로 피드백 받은 내용이 많은데,
어떤걸 채택할지 정리해가며 환경세팅을 시작하자!

npm / pnpm / yarn 차이

  • npm
    node.js의 기본 패키지 매니저, 가장 넓은 생태계와 다양한 기능 제공
  • yarn
    더 빠르고 안전한 설치
    'yarn.lock'으로 재현성 강화, 모노레포관리에 유리
  • pnpm
    디스크 공간 절약, 속도와 효율성이 뛰어남,
    심볼릭 링크를 활용한 독특한 구조

pnpm 채택!!

모노레포
여러 개의 프로젝트를 하나의 리포지토리에서 관리하는 방식

심볼릭 링크
파일 시스템에서 하나의 파일이나 디렉토리에 대한 포인터 역할을 하는 특별한 파일
윈도우의 바로가기와 비슷한 개념

yarn 보다도 성능, 디스크 효율성이 좋은 pnpm채택

iwr https://get.pnpm.io/install.ps1 -useb | iex

일단 bash로 설치가 안되서
powershell로 pnpm 설치

 pnpm create next-app ShareLife

이렇게 했더니

name can no longer contain capital letters

대문자여서 생성 불가

pnpm create next-app share-life

로 진행 후

Typescript로 사용할 것이며,
코드 품질 향상, 일관성에 도움 주는 ESLint도 사용할건데,
Tailwind CSS가 고민되었다

ShadCN과 Tailwind CSS
ShadCN은 Tailwind CSS와 함께 사용할 수 있는 UI 컴포넌트 라이브러리
Tailwind CSS 기반의 스타일링 제공
Tailwind 유틸리티 클래스 활용해 커스터 마이즈 가능
이미 잘 설계된 UI 컴포넌트에 Tailwind CSS의 유틸리치 추가하여 스타일 손쉽게 조정

Next에서의 TailwindCSS + ShadCN vs Styled-Components

  1. TailwindCSS + ShadCN
  • 유틸리티 퍼스트 접근법
    클래스 기반 스타일 빠르게 적용, 디자인의 일관성 쉭베 유지
  • 빠른 스타일링
    미리 정의된 유틸리티 클래스 사용하여 빠르게 스타일 적용, 직관적
  • 커스터마이즈
    ShadCN은 Tailwind CSS의 유틸리티 클래스 활용하여 컴포넌트 스타일 조정
  • 일관성
    디자인 시스템 일관되게 유지 가능,
    다양한 UI 컴포넌트 통합적 관리
  • 경량화
    Tailwind CSS는 필요 없는 스타일 제거, 최종 빌드서 CSS 파일 크기 줄일 수 있음 (이게 매우 메리트 있어보임!!)
  1. Styled-Components
  • CSS-in-JS
    컴포넌트 단위 스타일 적용
  • 동적 스타일링
    props사용
  • 스타일 캡슐화
    스타일 충돌 방지(각 컴포넌트 스타일 독립적)
  • 테마 지원
    스타일 일관성 유지 도움

즉,
Tail+Shad는 빠른 개발 속도, 스타일 일관성, 유틸리티 클래스 기반 직관적

Styled는 컴포넌트 단위 스타일 정의, 동적 스타일링
복잡한 상태 기반 스타일링 테마 관리 용이

나는 복잡한 상태 관리 안할 것 같고, next에서도 기본 옵션에 tailwind를 물으므로 ShadCN + Tailwind CSS 채택!!

코드가 커지고 복잡해질경우 src 디렉토리를 사용하는게 프로젝트 구조가 명확해지고 유지보수가 용이해지며, 일관된 코드 구조를 유지하고, 표준화된 접근 방식을 사용할 수 있어서.
권장하는 편이 많다하니 나는 소규모 프로젝트 개인프로젝트지만 숙련도를 위해 채택!


코드 베이스의 모듈 경로 관리 방식

yes라면 커스터마이즈할 수 있어
import Button from '../../components/Button'
이런 방식을
import Button from 'components/Button'으로 변경 가능

대신 초기 세팅을 tsconfig.json 에서 경로 별칭을 설정해줘야함.
근데 여러 경로 별칭을 사용하게되면 프로젝트가 커지면 경로 관리 복잡해질 수 있음

NO를 선택하면 직관적인 경로 사용하지만,
깊은 폴더구조에선 코드가 너무 복잡해질 수 있음.

이것도 팀 프로젝트를 한다면 사용할 가능성이 높으므로 yes를 선택해보겠다!

최종적으로 세팅한 모습. 물론 손수 세팅해줘야하는 추가적인 부분이 있을 것을 알지만 pnpm으로 만들었잖아 한잔해~


pnpm으로 설치해서 그런가 먼가 엄청 빨리 다운된 기분 진짜로 성능 체감이 느껴지는 것 같았다


일단 next dev는 정상적으로 잘 실행되는 모습

그 후 다른 초고수분들의 기본 세팅을 참고해서 더 최적화를 진행해보면

webpack 번들 파일 최적화 설정

빌드 파일 생성 시, 번들 파일 용량 압축 등 번들링 최적화 위해 webpack의 optimization 설정

pnpm add -D terser-webpack-plugin

이걸 하게되면 terser-webpack-plugin을 설치하게 되는데,
JS 코드 압축, 최적화 하는데 사용되는 플러그인, Webpack 빌드 과정 유용함
1. 코드 압축 및 최적화

  • JS 코드 축소
  • 불필요한 코드 제거(알아서)
  1. 성능 향상
  • 빠른 빌드 시간
    멀티코어 프로세서를 활용해 더 빌드 속도가 빨라짐
  • 최적화된 결과물
    최적화된 JS 파일 제공함으로써, 페이지 초기 로딩 속도와 렌더링 성능 개선
  1. 설정의 유연성
  • 플러그인 옵션
    다양한 설정 옵션을 제공하여 코드 압축 수준과 난독화 수준 조절
    (최적화 수준, 공통 코드 제거, 디버깅 정보 제거 등)
  • 병렬 처리
    빌드 성능 향상, CPU 자원 효율적 활용

그 후 적용할 파일이 next.config.js인데 내가 설치된 파일은 next.config.mjs였다

next.config.js 와 next.config.mjs의 차이
next.config.js
CommonJS 모듈 시스템을 사용하여 module.exports를 통해 설정 내보냄. 전통적인 Node.js환경에서 사용
next.config.mjs
ES Modules을 사용하여 export defualt를 통해 설정을 내보냄. 최신 JS표준 사용하는 방법
import와 export 문법 사용
모듈도 require이 아닌 import로 가져옴

그렇게해서 플러그인을 잘 설치했으니 환경 세팅을 하였는데, 

import TerserPlugin from 'terser-webpack-plugin';

const isProduction = process.env.NODE_ENV === 'production';

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack(config) {
    if (isProduction) {
      config.optimization = {
        ...config.optimization,
        minimize: true,
        minimizer: [
          new TerserPlugin({
            parallel: true,
            terserOptions: {
              format: {
                comments: false, // 주석 제거
              },
              compress: {
                drop_console: true, // console.* 구문 제거
              },
            },
            extractComments: false, // 주석을 별도의 파일로 추출하지 않음
          }),
        ],
      };
    }
    return config;
  },
};

export default nextConfig;
  1. import TerserPlugin from 'terser-webpack-plugin'
    ES Modules 방식으로 플러그인 가져옴(require로 가져왔으면 에러가 났을 것임)
  2. const isProduction = process.env.NODE_ENV === 'production'
    현재 환경이 프로덕션인지 여부 확인
  3. webpack(config)
    Webpack 설정 커스터마이즈
    isProduction이 true인 경우에만 plugin 설정
    즉, 개발 환경에선 최적화 진행 X
  4. config.optimization
    Webpack의 최적화 설정을 업데이트
    minimize: true => 코드 압축 활성화
    minimizer => 압축 플러그인으로 TerserPlugin 설정
  5. TerserPlugin({...})
    parallel: true => 병렬 작업을 활성화하여 빌드 성능 향상
    terserOptions: Terser의 압축 옵션 설정
    format: {comments: false} => 주석 제거
    compress: { drop_console:true}: console.* 구문 제거
    extractComments: false => 주석 별로의 파일로 추출하지

적다보니 느낀건데 그러면
굳이 코드에서 주석이나 console을 제거할 필요없다는 뜻!!!! 와우!!!!'

그리고 NODE_ENV === 'production' 이 부분은 프로덕션환경일때만 terser plugin은 가동한다는 의미인데, 파일을 만들어 주자

이전 terser 플러그인 도입 전 배포시간 9초

도입 후 6초!!

확실히 개선되었다 webpack 성능 향상 굿~~
심지어 프로덕션 모드일땐 더 최적화가 진행되니 더욱 체감이 되지 않을까 싶다

ESLint 설정 추가

현재 .eslintrc.json엔 next/core-web-vitals만 확장되어 있고, 추가로 코딩 스타일, 품질 강화를 위한 prettier 통합을 해줘야한다

pnpm add -D prettier eslint-config-prettier eslint-plugin-prettier

일단 prettier 설치


.eslintrc.json에 플러그인 설치한 prettier관련 세팅

prettier란
코드 포맷터
코드 스타일 일관되게 유지하고, 읽기 쉽게 자동으로 포맷팅 수행하는 도구

그 후 포맷팅 수행할 .prettierrc 파일 생성하여 포멧팅 규칙 정의

{
  "semi": false,
  "singleQuote": true,
  "trailingComma": "all",
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
  "arrowParens": "always"
}

semi : 문장 끝에 세미콜론 추가할지(next는 공식문서에서 세미콜론 사용 안한다고 함)
singleQuote : 문자열에 싱글쿼트 사용할지 더블 쿼트 사용할지(true면 싱글쿼트)
=> 따옴표 '쓸건지 "쓸건지 => '이게 편함!!!!
trailingComma : 마지막 요소 뒤에 쉼표 추가할지(all은 모든 경우에 쉼표 추가)
=> 마지막 줄에서 쉼표를 직접 추가안해도 알아서 쉼표를 넣어주므로 깔끔하고 일관되게 코드 유지에 유리
=> 요소가 없어도 ,가 들어있는게 어색하지만 오히려 일관성을 높이고 불필요한 변경 줄일 수 있다하여 요번에 채택해볼 예정

const arr = [1, 2, 3,]
const obj = {
  a: 1,
  b: 2,
}

useTabs : 들여쓰기에 탭을 사용할지 공백을 사용할지(false는 공백 사용)
=> 굳이 들여쓰기에 탭을 안써도 알아서 띄워서 커서가 위치하게 둠
tabWidth : 공백 또는 탭의 너비 2씩(4로하면 너무 코드가 길어짐)
printWidth : 한 줄의 최대 길이
arrowParens : 화살표 함수의 인자에 괄호 추가할지 여부(always는 항상 괄호 추가)

const add = (a, b) => {
  return a + b
}

const square = (x) => {
  return x * x
}

이러면 인자가 하나여도 무조건 괄호 추가

const add = (a, b) => {
  return a + b
}

const square = x => {
  return x * x
}

이러면 인자가 하나정도면 괄호 생략
이건 가독성을 위해 괄호 있는 버전이 좋음!!

그리고 prettier 뿐만 아니고 추가적으로 좋을만한것도 검색해봄

{
  "extends": [
    "next",
    "next/core-web-vitals",
    "prettier",
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended",
    "plugin:react-hooks/recommended"
  ],
  "plugins": ["prettier", "@typescript-eslint", "react", "react-hooks"],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json",
    "createDefaultProgram": true
  },
  "rules": {
    "prettier/prettier": ["error"],
    "react/react-in-jsx-scope": "off",
    "no-console": "warn",
    "no-unused-vars": "warn",
    "import/prefer-default-export": "off"
  },
  "ignorePatterns": ["node_modules/"]
}

이렇게나 길어졌다 eslint가 ㅎㄷㄷ
저중에 패키지를 설치해야 사용 가능한 것들이 있는데,

pnpm add -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-prettier eslint-config-prettier eslint-plugin-react eslint-plugin-react-hooks
  • eslint : ESLint 본체
  • @typescript-eslint/parser : TypeScript를 ESLint가 이해할 수 있도록 돕는 파서
  • @typescript-eslint/eslint-plugin : TypeScript 코드에 대한 ESLint 규칙 제공
  • eslint-plugin-prettier : 앞서 진행했던 Prettier ESLint 통합위한 플러그인
  • eslint-config-prettier : 위와 같음(Prettier와 충돌할 수 있는 ESLint규칙 비활성화)
  • eslint-plugin-react : React관련 ESLint 규칙 제공
  • eslint-plugin-react-hooks : 훅 관련 ESLint 규칙 제공

이제 설치 후에 위에 있는 코드를 사용할 수 있게 된건데
"extends"

  • next : next의 기본 ESLint 규칙 사용
  • next/core-web-vitals : core web vitals 관련 규칙 포함(웹 성능, 사용자 경험)
  • prettier : prettier 관련 규칙 포함, prettier, ESLint 충돌 방지
  • plugin:@typescript-eslint/recommended : Ts코드 위한 권장 ESLint 규칙 포함 TS문법 스타일 체크
  • plugin:reactrecommended : React 기본 규칙 포함
  • plugin:react-hooks/recommended : react hooks사용 시 권장되는 규칙 포함

"plugins"
위에 설치 코드로 설명함

"parser"
마찬가지

'parserOptions'

  • project : /.tsconfig.json : Ts설정 파일 경로 지정
  • createDefaultProgram : true : 프로젝트 설정 명시되지 않은 파일에 대해서도 기본 프로그램 생성

'rules'

  • prettier/prettier : ["error"] : Prettier규칙 위반하면 다 오류 처리
    (이부분이 나중에 엄청 골때릴 예정 전에도 당해봤음 익숙해져야함 얼른)
  • react/react-in-jsx-scope : off : react 17이후 react를 import 하지 않아도 되어 규칙 끔(지금은 18버전 이상임)
  • no-console : warn 애초에 빌드할때 console무시하고 프로덕션에선 보이지만, 그래도 없애는게 좋다
  • no-unused-vars : warn 사용하지 않는 변수도 경고처리
  • import/prefer-default-export : off : 기본 내보내기 대신 명명된 내보내기 사용할 수 있도록 허용, 이러면 export, default export 둘 다 사용 가능

'ignorePatterns'

  • node_modules/ : 노드모듈 폴더는 ESLint 검사에서 제외, 외부 라이브러리도 포함이라 불필요함

먼가 시작도하기전에 설치랑 세팅만 주구장창 하는 기분이지만, 예전에 기획이 너무 늦어져서 주먹구구식으로 일단 개발부터 시작했더니 나중에 수장해야할 사항이 너~무 많아서 피곤했던 기억이 있으므로 기초 공사를 탄탄하게!!

이것 저것 다 세팅하고 오류가 있나 pnpm run dev를 해봤더니 빌드타임 6초에서4초까지 줄어든 모습!!

깃 연결

echo "# ShareLife-SNS-" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/gyugod93/ShareLife-SNS-.git
git push -u origin main

새로운 레파지토리 ShareLife만든 후 연결

husky와 lint-staged????

이번 세팅은 다른 프로젝트보다 압도적으로 오래 걸리는데, 새로운걸 다 적용해보고 싶어서이다.
위의 두개는
git commit할 때 커밋 프로세스를 효율적이고 코드 품질 유지하는 관리를 위한 도구

  1. Husky
    git 훅을 쉽게 관리할 수 있게 해주는 도구
    커밋 전 특정 스크립트 실행해 코드 품질 검사, 자동 수정 가능
  • 커밋 훅: 커밋 전 코드 스타일 검사 테스트 실행하는 스크립트 자동 실행
  • 푸쉬 훅: 푸쉬 전 특정 작업 실행하도록 설정 가능
  • 컨피그 파일: .husky 디렉토리에 설정 파일 배치하여 훅 정의
  1. lint-staged
    git 스테이징 영역에 있는 파일에만 린트 작업 수행하도록 설정하는 도구
    전체 코드 베이스 아닌 커밋에 포함된 변경 파일만 검사하여 작업의 효율성 높임
  • 부분적인 린트 : 커밋 시 변경된 파일만 린트하여 빠른 검사
  • 자동 수정: 린트 도구에서 자동으로 수정할 수 있는 문제 자동으로 수정
  • 통합: Husky와 함께 사용하여 커밋 전 자동 린트 실행

정리하자면, husky는 전체 파일 검사, lint-staged는 staging된 파일만 검사

느낌만 알겠으니 일단 설치해보며 체크해보자

pnpm add --save-dev husky

일단 설치

pnpm exec husky init

이 코드를 사용하면 Husky 초기 설정 진행, .husky폴더와 pre-commit 훅 생성됨


이렇게 생성된곳에 pnpm이 적혀있으니 테스트를 위해 

echo 'pre-commit 훅 테스트'
exit 1

을 적은 후 commit 해봅세

exit 1 코드 덕분에 commit 올라가는것 강제로 막음
exit 0일때 commit 올라가고 1일때 취소됨

실제 적용하려면 .husky/commit-msg파일 생성해서

이런식으로 담으면 테스트가 된다는데, 그러면 결국 파일이 commit-msg와 pre-commit 두개가 생긴 셈이다

  1. commit-msg훅
    커밋 메시지가 커밋이 저장되기 전 유효한지 확인해주는데 사용
    커밋 메시지를 검사하고 특정 형식에 맞지 않다면 커밋 거부

  2. pre-commit 훅
    커밋이 이루어지기 전에 실행됨

근데 이전에 pre-commit에 exit 1을 넣어놨기에 어떤 커밋 메시지를 작성해도 failed가 떳다

========================================
머리 아파서 처음부터 다시 시작

pnpm add husky lint-staged --save-dev

일단 이걸로 둘 다 한꺼번에 설치

pnpm exec husky install

husky 초기화(git 훅 설정할 수 있도록)
이제 .husky 디렉토리 생성됨

pnpm exec husky add .husky/pre-commit "pnpm exec lint-staged"

pre-commit 파일 생성하고, lint-staged 실행하는 명령어 추가

이후 package.json에

  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,scss}": "prettier --write"
  }

추가

이후 .eslintignore .prettierignore 파일 루트에 추가
그러면 린트와 포멧 작업에서 다양한 라이브러리가 있는 노드모듈은 제외함(검사 제외)

이후 커밋 메시지 유효성 검사 설정

을 위해 commitlint를 사용할 수도 있음

pnpm add --save-dev @commitlint/{config-conventional,cli}

이 명령어는 @commitlint/config-conventional과 @commitlint/cli를 개발 의존성으로 설치
커밋 메시지의 규칙 정의하는 설정 파일

이후 package.json 파일에

  "commitlint": {
    "extends": ["@commitlint/config-conventional"]
  }

추가하기

그럼 이제 Commitlint 훅을 추가해줘야한다

pnpm exec husky add .husky/commit-msg "npx commitlint --edit $1"

이 명령어로 .husky/comit-msg 파일 생성하고 커밋 메시지를 commitlint통해 검증하게됨

그러면 총 lint-staged를 사용하는 husky의 pre-commit과 commit-msg 두 파일이 생성되었는데,

pre-commit 파일

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

pnpm exec lint-staged

커밋전에 lint-staged를 실행해서 변경된 파일만 린트 밋 포맷팅함(속도 개선)

commit-msg 파일

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx commitlint --edit "$1"

커밋 메시지가 commitlint 사용해 검증되도록 세팅

여기서 말하는 commitlint는
앞서 @commitlint/config-conventional로 설치를 했었고,
그 형식은

<type>(<scope>): <subject>

[optional body]

[optional footer(s)]

이렇게 넣어야만 가능하다.
<>때문에 헤깔릴 수도 있는데 실제로는

  • 예시
'fix(auth): resolve login issue'
'feat(api): add new endpoint for use data'
'chore(deps): update dependency versions'
  • 규칙 설명
<type>:커밋 종류(feat,fix,chore,docs 등)
<scope>:변경된 범위(선택사항)
<subject>:변경의 간단한 설명
[optional body]: 변경 상세 설명(선택사항)
[optional footer(s)]:추가 정보(선택사항)

아마 type과 subject를 메인으로 사용하지 않을까 싶다

결국 husky와 lint-staged까지 git과 관련된 내용 해결!!!

profile
규갓 God Gyu
웹 개발자 되고 시포용
이전 포스트

팀 최종 프로젝트[BOOKER] 채팅파트 분석하기

다음 포스트

[개인 프로젝트 ShareLife] SNS 만들기 ShadCN & Tailwind CSS 적용

0개의 댓글