프론트엔드 빌드 환경을 정리해야 했는데 운영 서버의 Node 16 으로는 패치 없이 빌드가 안 됐다. 손으로 관리하는 패치가 여러 개 쌓여 있었고 누가 언제 왜 넣었는지 알 수 없었다.
Table of contents
Open Table of contents
배경 — 쌓여 있던 패치 스택
패치들은 --ignore-scripts 로 네이티브 애드온 빌드를 우회하거나 fsevents 같은 플랫폼 전용 패키지를 강제로 설치하는 내용이었다. 패치 없이 되는 버전이 있는지를 찾기로 했다.
package-lock.json 을 보고 각 패키지가 engines 로 요구하는 Node 범위를 정리했다. 요구가 위아래로 갈려 있었다.
원인 — 위아래가 다 막혔다
한 CLI 패키지가 node >= 14 를 요구하고 있었다. 그것이 아래쪽 경계였다.
빌드 도구는 node-sass@4.14.1 을 하드 의존으로 물고 있었다. node-sass 공식 문서의 지원 표는 4.14 판이 Node 14 까지라고 적고 그 위는 5.0 이후다. 위아래가 동시에 막혀 있는 상태였다.
조치 — 하나뿐인 교집합
두 조건을 겹치니 가능한 구간이 Node 14 하나뿐이었다. 운영은 그 구간 밖의 16 을 쓰고 있었고 그래서 node-gyp 가 거부했다.
패치 스택은 그 거부를 우회하려고 쌓인 것이었고 교집합을 계산하고 나서야 패치의 이유가 설명됐다. 길은 두 가지였다. 운영 Node 를 14 로 내리는 것과 node-sass 를 sass 로 바꿔 위쪽 경계를 없애는 것이다. 앞쪽을 골랐다. 이유는 지금 목표가 패치 제거이지 스타일 도구 교체가 아니라서다. 대신 곧 지원이 끝나는 판에 묶이는 것을 감수했고 교체는 다음 분기 항목으로 적었다.
주의 — 정적 분석의 한계
여기까지가 문서와 설정 파일을 읽어 낸 결론이었다. 그런데 확신이 서지 않았다.
의존의 의존까지 다 봤는지와 optionalDependencies 가 어떻게 되는지와 실제로 네이티브 바인딩이 컴파일되는지가 설정 파일에는 안 나오기 때문이다. 읽어서 얻은 것은 될 것 같다는 수준까지였다.
검증 — 실제 설치로 한 확정
그래서 docker run node:14 로 컨테이너를 띄워 실제로 설치를 돌렸다. python3 과 make 와 g++ 를 깔고 npm ci 로 잠금 파일 그대로 설치하니 4분 만에 정상 종료했다.
종료 코드만으로는 부족해서 vendor/ 아래 binding.node 가 실제로 생겼는지와 require('node-sass') 가 로드되는지까지 확인했다. 그것으로 확정하고 패치 스택을 전부 제거했으며 fsevents 는 리눅스에서 건너뛰면 되는 것이라 억지 설치도 없앴다. 정적 분석으로 결론이 갈릴 때는 실제 설치를 돌리는 것이 유일한 확정 수단이고 읽어서 후보를 좁힌 뒤 실행해서 확정한다.
정리
- 의존들의 요구 범위를 겹치면 가능한 버전이 나온다
- 교집합이 하나뿐일 수 있고 그러면 선택지가 없다
- 운영이 그 밖의 버전을 쓰면 패치가 그 이유다
- 정적 분석은 될 것 같다까지만 말한다
- 실제 설치를 돌려 확정한다
- 종료 코드와 생성된 바인딩과 로드까지 확인한다
- 이유가 없어진 패치는 남길 이유도 없다
- 툴체인 전체를
.nvmrc로 명시적으로 고정한다