npm v12의 예정된 호환성 깨짐 변경

postinstall 스크립트는 오래전에 제거됐어야 했고, NPM 패키지의 암 같은 존재임
뭔가를 가져올 때 깊게 중첩된, 통제되지 않는 postinstall들이 무작위로 실행되는 게 너무 많음
누가 어느 시점에 이걸 좋은 생각이라고 봤는지 모르겠음

post-install 스크립트 우려의 핵심을 잘 이해하지 못하겠음
보통은 패키지된 의존성 코드를 어차피 어느 시점엔 실행하고, 대개 설치 과정과 같은 권한으로 실행함
그러면 이런 설정 스크립트들은 좋든 나쁘든 진입점을 npm에서 import나 require가 일어나는 곳으로 옮기면 됨
전체 생태계가 Deno 같은 샌드박스 환경으로 옮겨가지 않는 한, 기껏해야 작은 걸림돌처럼 보임. 그게 계획일 수도 있겠지만

기본값 변경이라 보안 태세 변화로 볼 수는 있지만, 보안 수정 자체는 모두가 이미 적용 가능함
글에 나온 대로 적절한 기본값을 설정하면 끝임
이 변화의 가장 좋은 점은, 기본값이 바뀌면서 새 개발자들이 그냥 install을 실행했을 때 이런 설정이 켜져 있다고 가정하는 성가신 패키지들이 즉시 깨지는 걸 보게 된다는 것임
예를 들어 스크립트가 실행 가능하다고 기대하는 관행을 멈추게 만들 수 있음

글만 봐서는 명확하지 않지만, 스크립트 허용 목록이 전역 설정이 아니라 패키지별 허용을 지원하는 것 같음
특정 패키지에만 스크립트를 허용하는 조직 단위 규칙을 유지하기 쉬워질 듯함
이런 식으로 패키지 관리자 설정에서 안전하지 않은 기본값을 막는 데 쓸 수 있는 린터가 있는지 궁금함

grep이면 되지 않나?

아직도 Yarn을 쓸 이유가 있는지 궁금함
Yarn도 공급망 공격을 막는 보호 장치를 구현했는지 모르겠음
지금까지는 pnpm만 알고 있었는데, npm도 따라온 건 좋음

당연히 있음
최신 Yarn 릴리스인 4.x는 지나칠 정도로 결정적 동작을 보장하고, 팀 전체에서 일관된 동작을 기대할 수 있음
기능 면에서는 작은 디테일들이 많고, 익숙해지면 합쳐져서 차이가 커짐
다음 메이저 릴리스도 더 나은 성능과, 그 성능 개선에 의존해서 지금까지 구현하지 못했던 기능들로 같은 방향을 계속 밀고 갈 예정임
참고로 Yarn의 리드 메인테이너임

초기부터 v3까지 Yarn을 쓰던 프로젝트에서 일했는데, 엄청 느리지만 동작은 함
공급망 보호 기능도 있음
결국 참지 못하고 pnpm으로 옮겼고, CI와 로컬 개발 머신 모두에서 설치가 훨씬 빨라졌음
LLM의 도움을 받아 마이그레이션하는 데 하루 정도 걸렸음

차별점 중 하나는 선택 가능한 설치 전략으로, 패키지를 node_modules에 풀지 않고 압축 아카이브에서 직접 실행하는 방식임 https://yarnpkg.com/features/pnp
Java에서 .class 파일 디렉터리 트리 대신 .jar를 쓰는 것과 꽤 비슷함
다만 약간 해키하고, 편집기와 도구 지원은 제각각임
작은 파일 수가 훨씬 적어서, 어쩔 수 없이 Windows에서 작업해야 한다면 특히 더 빠를 수 있음
아카이브를 git 저장소에 넣을 수도 있어서, 인터넷과 패키지 레지스트리에 대한 의존을 제거할 수 있음