DevOps

Build > Deply > Test > Release

node

LTS 버전이란?
개발 환경의 변화로 인해 문제가 나타날 수 있다.
최신 버전은 새로운 기능이 포함되어있지만 안정성에대한 검증이 완벽히 되지 않은 버전이다.
LTS 버전은 안전성이 보장된 최신 버전이라 생각할 수 있다.

nvm

1. 설치
   brew 설치 https://velog.io/@jinic/brew

brew install nvm

2. 설정

brew info nvm // 명령어에서 안내대로 추가 진행

https://stackoverflow.com/questions/53118850/brew-install-nvm-nvm-command-not-found

// 생성
touch ~/.bash_profile || touch ~/.zshrc
// 작성(brew info nvm 안내대로 진행)
vi ~/.bash_profile || vi ~/.zshrc
// 재실행
source ~/.bash_profile || source ~/.zshrc

Oh my Zsh 설치하면 재 설정 필요

3. node 버전 설치/변경/확인

nvm install --lts
nvm install x.x.x
nvm use x.x.x
node -v

// nvm 으로 설치한 node 버전 확인
nvm list

node_modules

• node_modules폴더는 .gitignore에 추가
  https://stackoverflow.com/questions/22924633/gitignore-is-not-ignoring-directories

  git rm -r --cached node_modules
  git commit -m "removing node_modules"

• npm config
npm config
npm config list : 현재 설정된 값
  npm config set metrics-registry <패키지설치경로> --global
npm config set registry https://your-registry-url
npm install <패키지명> --registry=https://your-registry-url

Dependencies, Dev Dependencies, Peer Dependencies

• Dependencies
  런타임, 빌드타임, 개발중 모두 필요한 패키지
  앱이 빌드 될 때 이 종속성 패키지들도 번들에 포함되어 배포됨
• Dev Dependencies
  런타임에서는 필요하지 않고 빌드타임, 개발중에만 필요한 패키지
  빌드타임에서 이 종속성 패키지들은 빌드에 도움을 주거나 참조 되지만 번들에는 포함되지 않음
• Peer Dependencies
  사용자가 설치해야할 종속성 명시
  ex. 리액트 컴포넌트 라이브러리를 개발했다면 사용자의 앱에 설치할 때 리액트를 통째로 들고 올 것이 아니라, 해당 앱에 설치되어 있는 리액트를 사용하도록 말해줌

패키지 재설치

rm -rf node_modules
rm -f package-lock.json | rm -f yarn.lock // lock 파일 삭제 
npm cache clean --force

Build Tool

https://buddy.works/blog/webpack-vs-gulp
https://kdydesign.github.io/2017/07/27/webpack/

Gulp

gulpfile.js 파일을 기반으로 실행하는 Task Runner
Task Runner = 반복 가능한 특정 작업들을 단순 자동화한 것
(배포, 테스트와 같은 미리 정의해 놓은 어떤 작업들을 자동화하여 실행)
빌드속도가 빠름, 구축 시간이 적게 걸림
작은 규모의 개인프로젝트에서 사용

Webpack

package.json의 script를 기반으로 동작하는 Package Bundler
Package Bundler = 종속성을 가진 어플리케이션 모듈을 정적인 소스로 재생산
(소스들을 하나의 패키지화 하는 것)
Webpack = Gulp + 의존성 관리 기능 + 솓고 빠름

entry
의존성의 시작점
Webpack은 모든 파일을 모듈로 관리한다.
Webpack에서 모듈이 많아질수록 서로의 의존성은 높아진다.

output
Webpack을 이용하여 빌드하고 번들된 파일의 위치를 지정

loader
파일을 해석하고 변환하는 과정에 관여하여 모듈 처리
Webpack은 javascript밖에 알지 못하므로 css,scss,babel,file 등은 loader로 등록해줘야 Webpack이 빌드할 때 인식을 할 수 있다.

plugin
해당 결과물의 형태를 바꾸는 역할을 하므로 번들링된 파일을 처리한다.
결과물에서 스타일 코드만 뽑아서 별도 css 파일로 만들어 역할에 따라 파일을 분리하는것이 가능하다.

자바스크립트 패키지 매니저, 패키지 관리 툴

npm

Node.js의 기본 패키지 관리자
command-line client인 npm과 온라인 데이터베이스인 npm registry로 이루어져 있으며, 일반적으로 command-line client를 npm이라고 생각하는데, 실제로 npm에는 npm registry까지 포함되어 있습니다.

Node.js의 기본 패키지 관리자

장점
: 세계 최대 규모의 패키지들을 보유하고있음

단점
: 저장소의 취약한 보안 이슈
: 여러 패키지 설치 시 이전 패키지 설치가 완료 된 뒤 다음 패키지 설치로 시간이 오래걸림
: 패키지가 많아짐에 따라 빌드 성능이 떨어짐

npmrc

npm 패키지 매니저의 동작 사용자 지정

• shamefully-hoist=true
  : 일반적으로 npm은 종속성을 각 패키지의 node_modules 폴더에 설치합니다. 그러나 이 옵션을 사용하면 모든 종속성을 최상위 node_modules 폴더로 이동시켜 중복을 줄입니다. "shamefully-hoist"라는 용어는 이 작업이 관례적이지 않고 조심스러운 방법이라는 의미에서 사용됩니다.
• strict-peer-dependencies=false
  : 이 설정은 false로 설정되어 있으므로, npm이 peer 종속성에 대한 엄격한 검사를 수행하지 않습니다. peer 종속성은 패키지가 특정 버전의 다른 패키지와 함께 사용되어야 함을 나타냅니다. 이 설정을 사용하면 이러한 검사를 건너뛰고 종속성을 설치할 수 있습니다. 이것은 종종 개발 및 테스트 환경에서 편의를 위해 사용됩니다.
• https://www.daleseo.com/js-npm-config/

yarn

페이스북에서 만든 자바스크립트 패키지 관리자
npm과 같은 기능을 수
npm에 단점(속도, 안정성, 보안성)을 느껴 만들어 짐

npm에 단점(속도,안전성,보안성)을 느끼고 페이스북에서 만든 자바스크립트 패키지 매니저
npm과 같은 기능 수행

장점
: 여러 패키지 설치 시 병렬 설치로 속도가 빠름

단점
: yarn.lock 파일의 버전관리로 인해 기존 모듈이 최신화로 업데이트 될 수 있으며 이 경우 하위 호환을 보정하지않는 모듈에서 에러가 날 수 있음
: 디스크 용량을 좀 더 많이 잡아먹는 편

명령어
: https://classic.yarnpkg.com/en/docs/cli/install

npm vs yarn

lock 파일은 둘 다(package-lock.json, yarn.lock) 있어도 되지만 npm과 yarn의 패키지 관리 방식이 다르기 때문에 한 번 사용하기 시작한 패키지 관리자로 계속 작업을 진행하는게 패키지 충돌 오류를 막아줌
yarn이 npm의 개선버전으로 나왔다고는 하지만 npm도 지속적으로 개선되는 중
npm
: 각 설치한 패키지별로 서브패키지를 이루는 형식
: 각 설치한 패키지의 독립성이 보장되지마 패키지 중복으로 인한 크기가 전체적으로 커짐

yarn
: 설치한 패키지와 종속되는 패키지를 공통적으로 사용할 때 일렬로 나열한 뒤 설치 패키지로 링크하는 방식
: 패키지 중복이 제거되어 적은 용량으로 빠른 실행 가능
: 네이티브 및 yarn을 고려하지 않은 버전 관리로 인한 드문 케이스로 패키지 충돌 가능성

참고
https://javascript.plainenglish.io/npm-vs-yarn-choosing-the-right-package-manager-a5f04256a93f

https://velog.io/@khy226/Yarn-%EC%9D%B4%EB%9E%80

패키지 관리 매커니즘

• 패키지 관리 툴의 종류에 상관없이 프로젝트의 메타정보는 package.json 파일을 통해 관리
• package.json 파일만 있으면 해당 프로젝트가 의존하고 있는 모든 패키지를 설치할 수 있기 때문에, node_modules 디렉터리는 Git 저장소에 올리지 않음
• package.json에서는 ^나 ~등을 이용해 범위를 지정한 경우가 많음 (따라서 모든 개발자가 동일시간에 패키지를 설치하지 않는 이상 개발자들은 서로 상이한 버전의 패키지를 설치할 확률이 매우 높아 이러한 상황을 해결하기 위해 패키지 관리툴에서 패키지 잠금을 지원하기 시작)

패키지 잠금 파일

패키지 잠금 파일에는 프로젝트의 패키지가 최초로 추가될 때 정확히 어떤 버전이 설치되었었는지 기록된다. 잠금 파일이 생성되면 잠금 파일에 명시된 버전으로 패키지를 설치해주어 설치 시점에 상관없이 항상 동일한 버전의 패키지가 설치되는 것을 보장 받을 수 있다. 잠금 파일을 Git 저장소에 올려두면 프로젝트의 모든 개발자의 PC뿐만 아니라 애플리케이션이 배포되는 서버까지도 npm registry에 배포된 최신 버전을 무시하고 잠금파일에 기록된 버전을 기준으로 패키지가 설치된다.

프로젝트를 최초 셋업하는 개발자는 패키지 잠금 파일을 Git 저장소에 반드시 올려서 다른 개발자들이 패키지 잠금 파일을 기준으로 패키지를 설치할 수 있도록 해야한다.
패키지 잠금 파일은 패키지 매니저가 신규 패키지를 설치하거나 기존 패키지를 갱신/제거할 때마다 package.json과 자동으로 동기를 맞춰주기 때문에 개발자가 이 파일을 직접 수정해야 할 필요는 없으며 해서도 안 된다.
신규 패키지를 설치하거나 기존 패키지를 갱신/제거한 개발자는 package.json과 더불어 함께 업데이트된 패키지 잠금 파일을 반드시 커밋해야 한다.
gitignore 에는 추가하지 말자.
https://blog.naver.com/gingsero/222140320340
https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5

npm: https://docs.npmjs.com/files/package-lock.json
yarn: https://yarnpkg.com/lang/en/docs/yarn-lock/

패키지 버저닝

참고 : https://blog.outsider.ne.kr/1041

MAJOR.MINOR.PATCH
MAJOR version when you make incompatible API changes, (API의 호환성이 깨질만한 변경사항)
MINOR version when you add functionality in a backwards-compatible manner, (하위호환성을 지키면서 기능이 추가된 것)
PATCH version when you make backwards-compatible bug fixes. (PATCH 버전은 하위호환성을 지키는 범위내에서 버그가 수정된 것)

틸트(~)
현재 지정한 버전의 마지막 자리 내의 범위에서만 자동 업데이트
~0.0.1 : >=0.0.1 <0.1.0
~0.1.1 : >=0.1.1 <0.2.0
~0.1 : >=0.1.0 <0.2.0
~0 : >=0.0 <1.0

캐럿(^)
^1.0.2 : >=1.0.2 <2.0
^1.0 : >=1.0.0 <2.0
^1 : >=1.0.0 <2.0

기타

Babel

Lint

Prettier