저는 한동안 생태계 전체의 성능을 높이기 위해 열심히 노력해 왔습니다. 일반적으로 오래된 종속성 트리를 정리하고 설치 공간을 줄이고 일반적으로 사용되는 종속성의 CPU/메모리 성능을 향상시킵니다.
이 블로그 게시물은 e18e와 생태계 정화로 이어지는 여정 중 일부를 간략하게 설명하기 위한 것입니다.
마이크로 유틸리티는 설치 크기와 많은 프로젝트의 종속성 트리 복잡성을 높이는 주요 원인입니다.
is-number 및 is-nan과 같은 패키지가 이 범주에 속합니다.
중요한 점은 이러한 패키지 중 상당수가 일부 상황에서는 사용되지만 일반적인 사용 사례에서는 확실히 그렇지 않다는 것입니다.
일반적으로 다음과 같은 상황에서는 교체할 수 있습니다.
예를 들어 is-number는 값이 숫자인지 또는 NaN이나 +/-무한대가 아닌 숫자형 문자열인지 확인합니다.
일부 프로젝트에서는 검증이 반복되어 자체 모듈이나 패키지로 추출되는 것이 더 좋습니다.
그러나 일반적인 경우에는 많은 소비자가 NaN 및 Infinity 검증이 필요하지 않았으며 숫자와 유사한 문자열을 지원하는 것조차 필요하지 않았습니다.
이를 통해 다양한 프로젝트에서 몇 가지 개선이 가능해졌습니다. 해당 프로젝트에서 이 패키지의 사용을 훨씬 간단한 인라인 로직으로 대체할 수 있습니다(예: 많은 실제 프로젝트에서는 해당 프로젝트가 나중에 값을 실제 값으로 가정하고 의존했기 때문에 안전하게 typeof n === 'number'로 전환했습니다). 번호는 어쨌든).
instanceof를 사용하여 정규 표현식인지 테스트할 수 있습니다: v instanceof RegExp.
그러나 일부 상황(예: 가상 컨텍스트 사용)에서는 RegExp가 v가 시작된 클래스와 동일하지 않기 때문에 작동하지 않습니다. 그러한 경우에는 다음과 같은 것을 사용해야 합니다:
Object.prototype.toString.call(obj) === '[object RegExp]'
이러한 코드를 인라인하고 싶지 않고 가상 컨텍스트 또는 이와 유사한 것을 지원해야 하는 경우 라이브러리가 적합할 수 있습니다.
그러나 많은 경우 프로젝트는 어쨌든 가상 컨텍스트를 지원하지 않았습니다(그리고 원하지도 않았습니다). 그러면 간단한 인스턴스로 다시 단순화할 수 있는 기회가 열립니다.
또 다른 개선 가능성이 있는 영역은 이전 런타임 지원입니다.
많은 인기 패키지에는 다양한 폴리필과 유사한 모듈의 매우 깊은 종속성 트리가 있습니다. 이는 일반적으로 다음 이유 중 하나 또는 둘 모두로 인해 존재합니다.
우리 중 대부분은 이 수준의 이전 버전과의 호환성이 필요하지 않으며, 이를 제거하면 성능이 크게 향상될 수 있습니다.
물론 이러한 제약 속에서 작업해야 하는 필요인 사람들이 여전히 있다는 점을 기억하는 것이 중요합니다. 이것이 바로 이 분야에서 우리가 기존 패키지를 변경하려고 시도하기보다는(어차피 그러한 변경이 허용되지 않는) 포크나 대안을 제공하는 경우가 많았던 이유입니다.
저는 2018년쯤부터 아주 작은 프로젝트에서도 내 node_modules가 얼마나 크고 깊게 중첩되어 있는지 확인한 후 이러한 특정 영역에 대해 생각하기 시작했습니다.
처음 몇 번의 변경 시도는 이러한 패키지를 감지하고 제거를 제안할 수 있는 일종의 ESLint 플러그인을 만드는 것이었습니다. 몇 달에 한 번씩 같은 생각을 하고 다시 시도했지만 실제로는 제가 원하는 위치에 도달하지 못했습니다.
이 기간 동안 저는 적어도 제가 할 수 있는 것을 정리하고 개선하기 위해 다양한 대규모 프로젝트에 기여했습니다(예: 제가 오랫동안 기여해 온 것은 스토리북입니다).
그런 다음 생태계 전체에서 가능한 성능 개선을 높이기 위한 저장소인 생태계 정리(기본적으로 문제 추적기)를 만들었습니다. 다시 말하지만, 이것은 기본적으로 한동안 나와 내 개인 이슈 트래커였지만 적어도 공개적으로는 볼 수 있었습니다.
얼마 지나지 않아 사람들이 문제에 관심을 갖고 업스트림 프로젝트에 기여하는 모습을 보기 시작했습니다. 나는 수년 동안 혼자서 이 문제를 해결하고 내가 변화를 만들고 있는지 궁금해하면서 이것을 보고 너무 기뻤습니다. 다른 사람들이 참여하는 것을 보는 것은 다른 사람이 관심을 갖고 있다는 것을 아는 데 큰 도움이 되었습니다.
청소 프로젝트는 과거에도 여전히 매우 유용했지만, 어떤 좋은 대안이 있는지 커뮤니티와 공유할 수 있는 곳이 없었습니다.
이를 해결하기 위해 모듈 교체 프로젝트를 만들었습니다.
이 프로젝트에는 기본적으로 교체 가능한 모듈의 일부 JSON 목록과 제안된 대안이 포함되어 있습니다. 이들은 현재 "엄격함" 또는 "의견"의 세 가지 수준으로 나뉩니다. 네이티브(네이티브 기능으로 대체될 수 있는 모듈), 마이크로 유틸리티(간단한 인라인 코드로 대체될 수 있는 모듈), 선호(우리가 생각하는 모듈) 더 성능이 좋은 대안으로 교체해야 합니다.
교체 프로젝트의 다음 단계는 codemod 세트를 생성하여 이러한 모듈 중 일부의 교체를 자동화하는 것이었습니다.
@passle이 주도한 이 프로젝트는 다양한 코드 모드 형태로 엄청난 양의 기여를 빠르게 받았습니다.
codemod 팀은 이를 codemod 플랫폼으로 포팅하는 몇 가지 훌륭한 작업도 수행했습니다. 앞으로는 일종의 CLI나 자동 수정 규칙을 통해서도 제공할 계획입니다.
이런 것을 아끼는 우리 모두가 서로를 찾았다고 느낀 전환점이 바로 e18e였습니다.
Bjorn은 Astro의 성능을 향상시키는 훌륭한 작업을 수행하고 있었고 Marvin은 생태계 속도 향상에 대해 비슷하게 글을 쓰고 있었습니다. 결국 우리의 길은 엇갈렸고 우리는 옆에서 좋은 논의를 나누었습니다.
우리 모두가 같은 생각을 갖고 있는지, 그리고 이를 기반으로 구축할 커뮤니티가 있는지 확인하기 위해 소규모 그룹이 함께 작업했습니다. 그러다가 e18e가 왔습니다!
생태계 성과 개선을 위해 사람들이 협력할 수 있는 커뮤니티 공간으로 구축된 이곳은 얼마나 많은 사람들이 이러한 것들에 관심을 갖고 있는지를 보여주었습니다. 정말 많은 분들이 가입하셨고 이미 막대한 금액을 기부해 주셨습니다. 우리는 생태계 전체에서 거의 매일 속도 향상과 크기 감소를 목격하고 있습니다.
커뮤니티는 빠르게 성장하고 있으며 기여에 감사할 사람이 너무 많습니다. 하지만 특히 이 커뮤니티를 가능하게 하는 데 도움을 주신 다음 분들께 감사의 말씀을 전하고 싶습니다.
마찬가지로, 이미 동일한 목표에 기여하는 프로젝트를 병행하고 있는 사람들:
위 내용은 JS 생태계 정리 및 속도 향상 - 지금까지의 여정의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
