사내에서 사용하는 Node.js 12를 쓰는 곳이 있었다.
이 때문에 최신 javascript에 적용된 여러 기능(Nullish coalescing operator(??) 등)들을 사용하지 못하고 있어 팀원들의 요청사항이 생기고 있었다.
마침 12버전은 2022년 4월 30일을 끝으로 유지보수 기간이 만료가 되기 때문에 최신 LTS로 한 번에 올려보기로 했다.
작업에 도움을 준 tyler, grey에게 고맙다.
https://nodejs.org/ko/about/releases/ 에서 릴리즈를 확인할 수 있다.
개발, 배포, 운영서버의 환경을 점검해야 할 필요가 있었다.
1. ubuntu version
2. python, gcc, git version
3. node package version
4. package version up에 따른 바뀔 code 확인
2번에 대해서는 배포를 진행하면서 중요하다는 걸 알게됐다.
특정 packages에서 gcc와 python에 대해 최소버전을 명시했기 때문!
제목 | 개발서버 | 배포서버 | 운영서버 |
---|---|---|---|
ubuntu | 18.04 | 16.04 | 18.04 |
python | 3.7.2 | 3.5 | 3.5 |
gcc | 7.4.0 | 4.8 | 4.8 |
node.js | 12.xx | 12.0x | 12.xx |
npm | 6.xx | 6.xx | 6.xx |
컨테이너 이미지를 node16에 맞춰 새롭게 만들었다.
사전 지식)
구름의 모든 서비스는 goormIDE를 통해 개발환경을 구축하고 서비스를 배포 및 운영한다.
기존 node12의 환경에서 package.json에 명시된 패키지들을 살펴보면서 git documentation을 읽으면서 node16을 지원하는 버전을 찾아서 올렸다.(하면서 bug-fix가 필요한 패키지도 함께 업데이트를 진행했고 모든 걸 한꺼번에 올릴 시 어디서 문제가 터지는 지 찾기 힘들어 2개씩 올려진행했다.)
React
redux, javascript-serialize 등
webpack
babel, babel plugin, @loadable, style-loader, sass-loader, node-sass, webpack-dev-middleware, webpack-hot-middleware 등
환경 세팅
husky, prettier, jest 등
버전이 올라가면서 모듈별 deprecated된 함수들을 찾고 올바른 사용법에 맞게 변경작업 시작
[node12] 올바르게 변경된 부분은 git commit을 진행해서 publish 함.
[node16] git pull로 바뀐 package.json을 설치해보고 구동시켜보기
(당연히 다른 부분에서 에러가 터지므로 계속 반복)
ex) webpack과 webpack-dev-middleware!
webpack4, webpack-dev-middleware 3.7.2를 사용하고 있었다. 내 목표는 webpack-dev-middleware를 최신중에 4버전을 지원하는 구간을 찾아야했다.
npm에 webpack-dev-middleware의 최신이 5.3.1임을 확인
해당 패키지가 webpack4를 지원하는지 확인이 필요했다.
webpack-dev-middleware의 패키지를 확인하고자 github으로 들어와 package.json을 열어봤다.
아래로 내려보면 peerDependency로 webpack4를 지원하는 걸 확인 그러면 이제 할 작업은 3에서 5로 major버전이 2번 바뀌었다.
그 사이에 바뀐 패치사항을 확인해야 한다.
릴리즈 노트를 통해 major버전이 변경될 때, features, breaking changes를 확인했다.
바뀐 부분이 있다면 code에도 적용을 시켜줘야해서 중요하다.
아래에 보면 watchOptions가 지워졌다. 앞으로 webpack.config.js에서 가져다 써야 함으로 코드에 반영해주기로 했다.
webpack-dev-middleware는 3에서 5버전으로 올렸다.
그리고 실행해보면서 확인 완료.
이 작업을 다른 패키지들에도 동일하게 진행했다. 생각보다 평소에 버전관리를 안하다보니 시간이 오래걸렸던 거 같다.
node버전을 올리는 방법은 nvm, n도 있지만 해당 방법으로 올리는 걸 비추천한다!
n, nvm으로 올리면 node로 명령어를 실행했을 경우와 /usr/local/bin/node간의 명령어가 꼬이는 경우가 발생할 수 있다. 이 경우, EACCES가 발생할 수 있다.
기존에 있던 node와 관련해 전부 지우고 curl로 node를 직접 받는 편이 좋다.
# node가 어디에 설치되어있는지 확인
whereis node
# node 관련 모든 경로 삭제
rm -rf /usr/bin/node
rm -rf /usr/include/node
rm -rf /usr/local/bin/node
rm -rf /usr/local/include/node # legacy-node 인듯
rm -rf /usr/share/man/man1/node*
rm -rf /usr/local/lib/node_modules/
rm -rf /usr/local/bin/npm
rm -rf ~/.npm
rm -rf ~/.node-gyp
apt remove nodejs -y
curl -fsSL https://deb.nodesource.com/setup_16.x | sudo -E bash -
sudo apt-get install -y nodejs
# 혹시 아래와 같이 뜬다면 node 6버전 부터 받고 다시 16버전 받는거 반복
# node -v
# The program 'node' is currently not installed. You can install it by typing:
# curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
# apt install nodejs
node12에서 16으로 넘어오면서 npm 버전또한 6에서 8로 바뀌게 되었다.
이 경우에는 설치를 하기 위해서
1. npm cache clean -f
2. rm -rf node_modules, package-lock.json
3. npm install --legacy-peer-deps // peer-dependency가 맞지 않아도 일단 설치.
3번을 한 이유는, npm8로 넘어오면서 7일 때, 나온 peer dependency에서 막히면 설치를 멈추는 경우를 방지하기 위해서 진행했다.
기존에 실행하던 방법으로 서버를 켜보고 package.json에 바뀐 리스트 중 몇가지 주요기능들에 대해 확인해봤다.
여기까지 적어보면서 알게 된 점은
"무조건 버전 업이 정답은 아니지만 LTS는 파악할 수 있는 hook이나 기타 설정할 수 있는게 있을지 확인해보자"
"개발과 운영환경의 설정은 최대한 같게 유지하자"
배포와 관련해서는 다음 편에 적어보도록 할 예정이다.