Deno와의 우정은 끝났다, 이제 Node가 내 가장 친한 친구다

오랫동안 Deno를 쓰다가 Node로 돌아와 보니 최신 JavaScript 문법과 내장 API가 크게 개선돼 있었음. require() 없이 개발할 수 있고, Deno를 계속 쓰던 이유도 습관과 익숙함에 가까웠음 Deno 기반 정적 사이트 생성기를 Node로 옮기는 데 파일 시스템 API와 서버 구동 부분만 바꾸면 됐으며, 최소한의 수정으로 해당 사이트의 빌드가 15% 빨라짐 TypeScript도 직접 실행할 수 있지만, 의존성 패키지 안의 TypeScript는 처리하지 않아 패키지 배포에는 별도 빌드 도구가 필요했음 패키지 관리에는 PNPM을 선택해 설치 후 스크립트를 차단하고, 새 패키지 버전은 하루가 지난 뒤 설치하도록 설정해 악성 업데이트에 바로 노출될 위험을 줄임 Deno를 떠난 결정적 계기는 ZSH 통합 장애, JSR의 과도한 요청 제한, 동시 HTTP 요청 처리 버그였음. 런타임 혁신보다 스타트업 제품과 AI에 집중하는 회사 방향에도 실망함 Node로 돌아온 개발 경험 SvelteKit 클라이언트 프로젝트에서 한 달간 Node를 집중적으로 사용하면서, 오랫동안 Deno를 쓰는 사이 ECMAScript 지원과 API가 개선됐음을 체감함 예전의 불편한 API가 교체되거나 현대화됐고, 특히 require()를 볼 필요가 없어짐 Deno를 계속 사용한 데에는 습관과 익숙함이 작용했으며, 최근에는 서버 측 JavaScript 작성 자체에도 큰 의욕이 없었음 Oracle 상표 분쟁에 대해서는 긍정적인 결말을 기대하기 어렵다고 봄 패키지 관리와 공급망 방어 설정 Node 공식 설치 문서는 인터넷에서 받은 스크립트를 곧바로 bash에 전달해 NVM을 설치하도록 권장하지만, 이 설치 방식과 과거 NVM/NPM 사용 경험에 불만이 있음 Node 버전 전환 도구로는 Fast Node Manager(FNM)이 더 낫다는 평가를 들음 개인적으로는 최신 버전을 선호하지만, 클라이언트 프로젝트에는 안정적인 버전도 필요함 악성 패키지 우려로 PNPM을 선택했으며, 설치 후 스크립트 차단도 장점으로 꼽음 alias npm=pnpm, alias npx=pnpx를 추가했고, 지금까지 문제없이 사용함 처음에는 바이너리 이름이 고정된 스크립트 때문이라고 적었으나, 이후 심볼릭 링크를 사용했던 경험과 혼동했을 수 있다고 정정함 별칭은 NPM 설치를 전제로 한 안내문에서 명령을 복사할 때 유용함 pnpm-workspace.yaml에 min...