처음 발표된 후, 나는 생활의 질을 바꿀 수 있는 시간이 있다는 것을 발견했다.

시각적 종속성 트리

재구성 검색이 미래의 증명

데이터 세트 업데이트

npmbomb는 무엇입니까?

https://npmbomb.tmkn.dev/
npmbomb는 제가 만든 작은 사이트입니다. 여기서 유행하는 npm 모듈의 총 의존성 수량을 추측하여 npm 모듈에서 끊임없이 증가하는 전달 의존성 수량을 제시할 수 있습니다.프로젝트에 의존 항목을 추가하면, 이 의존 항목은 대량의 다른 의존 항목을 포함할 수 있습니다. 이 의존 항목은 모르지만, 지금은 프로젝트의 일부가 됩니다.
그것은 dependencies 필드의 모든 의존 항목을 마지막까지 간단하게 추적합니다.그래서 계산된 숫자는 깜짝 놀랄 수도 있다.
만약 네가 더 많은 것을 알고 싶다면, 너는 소개를 찾을 수 있다

시각적 종속성 트리

현재 종속 트리 탭이 있습니다. 이 탭으로 전환하면 표시됩니다.🎉 종속 트리.
이것은 전달할 수 있는 의존 항목의 수를 표시하고 링크 아이콘을 누르면 npm에 대한 링크를 제공합니다.

이 숫자들은 어떻게 계산합니까?

각 줄 오른쪽의 숫자는 전달할 수 있는 의존항 계수 또는 총 의존항 계수입니다.
React의 경우 숫자는 8입니다.
계산 방법은 다음과 같습니다.

3 React 자체의 직접 의존 항목 + 모든 package.json(1) 및 loose-envify(4)의 전달 의존 항목.prop-types 자체가 다른 의존항을 정의하지 않았기 때문에 전달 가능한 의존항 계수에 영향을 주지 않는다.
일을 빨리 유지하기 위해 나무 사용react-virtualized.
이외에도 트리 구성 요소는 사용자 정의됩니다.
대부분의 나무는 깊고 크지 않기 때문에 object-assign 정상적으로 작동할 수 있지만, 예를 들어 농담은 브라우저를 땀에 젖게 한다.
react-virtualized 모듈은 검색 페이지에서 이미 사용되기 때문에 트리 렌더링을 사용하여 잠재적인 렌더링 병목을 해결합니다.
Jest와 그 거대한 의존 트리로 돌아가면 첫 번째 작업 버전은 트리 데이터에 20MB의 JSON 부하만 생성합니다.
직접 형식은 다음과 같습니다.

interface IDependencyTree {
    name: string;
    version: string;
    transitiveCount: number;
    loop: boolean;
    dependencies: IDependencyTree[];
}

Jest와 같은 의존 나무는 표준이 아니지만, 분명히 이것은 너무 심하다.Gzip도 5MB입니다.
키의 길이를 단일 문자로 줄일 때 16MB입니다.
따라서, 나는 그것을 검색 테이블을 제공하고, 실제 끼워 넣는 형식의 참조 번호만 제공하도록 변경합니다 (id):
react-virtualized 값은 다음과 같습니다.

export interface IDependencyTreeConfig {
    //lookup
    data: ITreeData[];
    //nested tree structure
    tree: IDependencyTreeStructure;
}

export interface ITreeData {
    id: number;
    name: string;
    version: string;
    count: number;
}

export interface IDependencyTreeStructure {
    id: number;
    dependencies?: IDependencyTreeStructure[];
}

나도 키의 길이를 줄여서 그것을 더욱 줄일 수 있지만, 이런 방법을 통해 유효 부하는 이미 7MB로 떨어졌고, Brotli 압축을 사용할 때, 그것은 현재 약 47kb이다.Jest 같은 외부인에게는 받아들일 수 있다고 생각합니다.

재구성 검색은 미래의 증명이다

npmbomb의 장기적인 목표는 npm 모듈의 데이터를 가지고 있는 것이다.
지금까지 데이터 집합은 소수의 가장 유행하는 모듈에만 한정되었다.
따라서 검색의 구조는 이 유한한 데이터 집합을 위해 맞춤형이기 때문에 데이터의 증가에 따라 확장되지 않는다.
이 문제를 해결하기 위해 검색은 현재 tree 을 사용하여 결과를 표시합니다. (의존 트리처럼) 임의의 검색 결과를 지원합니다.
낡은 검색 구조에서 모든 내용이 메모리에 있기 때문에 aax 경쟁 조건 등이 나타나기 쉽지 않기 때문에 그 실현은 매우 간단하지만 데이터 집합이 끊임없이 증가함에 따라 이런 방법은 더 이상 실행할 수 없을 것이다.현재, 사용자가 입력을 멈춘 후에만 검색 요청을 터치하는 등 Ajax 경쟁 조건을 주의해야 합니다. 사용자가 다시 입력하기 시작하면 진행 중인 Ajax 요청을 취소하는 등 모든 것을 깨끗하게 처리하기 위해 검색 구조는 현재 react-virtualized 에서 지원됩니다.
다음은 새 검색입니다.
사실 그것은 낡은 것처럼 보이고 모든 변화가 막후에 있다.)

데이터 세트 업데이트

원본 데이터는 2019년 7월을 기반으로 하기 때문에 1년 후에 업데이트를 제공하는 것이 적합하다고 생각합니다. 따라서 현재 데이터는 2020년 7월을 기반으로 합니다.비록 이것은 이미 유행이 지났지만, npmbomb의 목표는 최신 데이터를 제공하는 것이 아니다.사실상 이것은 매우 도전적일 것이다. 왜냐하면 어떤 모듈의 새로운 버전이든 기존의 의존 트리를 바꿀 수 있기 때문이다.그것의 휘발성은 매우 높다.반면 npmbomb의 목표는 대부분의 최신 데이터에서 대체적인 숫자를 제공하는 것이다.
흥미로운 것은 npm 데이터 집합이 1년 동안 23.9GB에서 42.2GB로 증가했다는 것이다.
총 모듈 수는 1007928개에서 1332134개로 증가했습니다.그래서 1년 동안 npm는 3240206개의 새로운 모듈을 보았다.

다음은 뭐예요?

npmbomb에 대한 나의 생각:

데이터 세트 추가

다음 단계는 데이터 집합을 늘리는 것이다. 즉, 위탁 관리 데이터를 보는 옵션이다.이 데이터 집합은 현재 netlify를 통해 웹 앱과 함께 위탁 관리되고 있다.비록 이것은 매우 좋은 서비스이지만, 그것은 무료층의 사용을 삼키고, 나는 데이터 위탁 관리를 다른 곳으로 옮기고, 넷lify에서만 웹 응용 프로그램을 위탁 관리하고 싶다.나는 건의를 듣고 싶다.

의존 트리 개선

나무 보기 빵 부스러기

나무 노드에 멈출 때 경로를 표시합니다. 큰 나무는 길을 잃기 쉽기 때문입니다.

여과

사용자가 특정 모듈을 검색할 수 있도록 합니다.
트리에 나타나는 모듈의 위치 강조 표시

추가 정보

모듈에 대한 추가 정보(예:

관리자

발표 날짜

소스 코드 표시

등

추가 E2E 테스트

E2E 테스트가 있지만 제가 원하는 수준은 아닙니다.대부분의 테스트는 단원 테스트를 통해 완성되었다.

A11Y

이 프로젝트는 이미 원형 단계를 지났기 때문에 시청자들의 성장에 따라 무장애성에 투자하는 것은 의미가 있다.

집안일

트리 보기의 추가와 다른 작은 조정에 따라 지금은 한 걸음 물러서서 집안일을 할 수 있는 좋은 기회이다.
봐라, 나는 해야 할 생각과 일이 매우 많다.이것도 우호적인 일깨움입니다. npmbomb는 완전히 Open Source입니다.
새 트리 뷰 체크 아웃하기: https://npmbomb.tmkn.dev/
피드백 감사합니다.🙃