내가 어떻게 NPM을 이용해서 다운로드했는지...왜 너는 그들을 믿지 말아야 하는가

지난 한 달 동안 나는 package, with little to no users의 다운로드를 성공적으로 얻었고 누적 다운로드량이 100만 번을 넘었다🚀.
그것은 어떤 돈도 쓰지 않았고, 어떤 법률도 위반하지 않았으며, 거의 아무런 노력도 필요하지 않았다.
다음은 NPM에 대한 다운로드 통계 정보입니다.

🔮 환상

만약 당신이 NPM의 새 소프트웨어 패키지를 사용하는 것을 고려한 적이 있다면, 아마도 당신은 이미 매주 다운로드 통계 데이터를 고려한 적이 있을 것이다.
이것은 페이지에 표시된 첫 번째 지표이기 때문에 사용자에게 반드시 유용한 정보일 것이다.정확했어

응답자의 3분의 1은 새로운 방안을 채택하는 결정에 큰 영향을 미친다고 생각하는 것 같다.
문제는 다음과 같은 두 가지 이유로 유용한 지표가 아니라는 점이다.

사용자와 다운로드 수량

사이에 느슨(고작) 관계가 존재한다

이 시스템은 개발하기 쉽다

다운로드란?

이것은 매우 좋다discussed on the NPM Blog. 그러나 총괄적으로 말하면 이것은 NPMs 등록표에서 성공적으로 다운로드한 모든 가방(tarball)이다.
NPM은 이 통계가 출처(IP, 사용자 에이전트 등)를 고려하지 않는다고 공개했다.이것은 모든 다운로드가 평등하다는 것을 의미한다.

프로젝트에 새 패키지를 추가한 사용자

CI 실행 설치 종속성

한 로봇이 소프트웨어 패키지를 반복해서 다운로드하여 인기 있는 가상을 만들었다(이것은 당신을 위해 약간의 깔개를 만들었다)

이것은 CI를 빈번하게 실행하는 프로젝트가 통계 데이터를 다운로드하는 데 미치는 영향이 그 어느 그룹보다 크다는 것을 의미할 수 있다. (특히 npm 클라이언트 캐시를 고려할 때)

등기소

대량의 등록표는 다운로드 계수가 사용 상황을 정확하게 반영하지 못하는 또 다른 원인이다.NPM 다운로드 수는 NPM 공식 레지스트리에 다운로드된 것만 포함하고unpkg와github 등 레지스트리는 포함하지 않는다.

🧑‍💻 이용 시스템

면책 성명: 다운로드 통계 데이터가 얼마나 쉽게 이용되는지 보여주기 위해 이 점을 기록했다.그러나, 나는 네가 이렇게 하지 말라고 강력히 건의한다. 왜냐하면 이것은 성실하지도 않고, NPM회사의 자원을 소모할 필요도 없기 때문이다.
지금까지 모든 내용을 읽었다면 어떤 형태의'천재 해커 공격'도 필요 없다는 것을 알게 될 것이다.
반대로 우리가 필요로 하는 것은 소프트웨어 패키지를 여러 번 다운로드하는 방식이다.
로컬에서 어떤cron 작업이 있는 스크립트를 실행하는 것은 좋겠지만, 그다지 흥분되지는 않습니다.서버 없음을 사용하십시오!
너는 볼 수 있다full repo here.

스크립트 만들기

Lambda의 경우 다음 매개변수를 사용하는 함수를 만들었습니다.

package - 다운로드할 패키지

probability - 실행 가능한 다운로드 가능성

다음 논점은 소음을 높이는 데 목적을 둔다. 다운로드가 시간에 따라 변화하는 성질을 모의하는 것이다.
매번 달리기를 할 때마다 동전을 던지고 probability 파라미터를 사용하여 성공 확률을 평가한다.뒤집기에 성공하면 패키지를 다운로드합니다.

export const handler = async ({ package, probability }) => {
  // Simulate coin flip
  if (Math.random() > probability) {
    // Flip fail
    return;
  }

  // Flip success
  await downloadPackage({ package });
};

Lambda 실행

이 스크립트를 정상적으로 실행하기 위해 CloudWatch 이벤트를 설정하여 분당 한 번의 속도로 터치합니다.

// Terraform example
resource "aws_cloudwatch_event_rule" "lambda_trigger_rule" {
  name = "trigger-npm-install"
  description = "Trigger an NPM install"
  schedule_expression = "rate(1 minute)"
}

Terraform의 CloudWatch 이벤트 규칙 예
이벤트를 트리거할 때 특정 작업을 수행하기 위해 필요한 매개 변수로 Lambda를 가리키는 이벤트 대상을 설정합니다.

resource "aws_cloudwatch_event_target" "lambda" {
  arn = aws_lambda_function.install_package_lambda.arn
  rule = aws_cloudwatch_event_rule.lambda_trigger_rule.name
  input = jsonencode({
    package = "is-introspection-query"
    probability = 0.8
  })
}

Terraform의 CloudWatch 이벤트 대상 예

🚀 결과는요

배치 일주일 후, 결과는...사실 그렇게 인상적이지는 않다.사실은 일주일의 시간이 내가 예상한 것만큼 많지 않다는 것을 증명한다🤔.
그러나 안타깝게도 일부 조정을 거친 후, 우리는 매주 100만 번의 다운로드를 할 수 없다!

네, 맞아요. 0 사용자의 패키지는 urql와mobx 같은 패키지보다 다운로드량이 많아요.
너는 지금 문제를 보았니?

데이터 다운로드가 작동하지 않음

일은 이렇다. 천진난만하게 통계 데이터를 다운로드하는 것은 고작 쓸모가 없고, 최악의 것은 오도이다.
NPM 사이트의 큰 그림, 온라인 문화, 디스플레이package download "trends"라는 제3자 사이트. 이 모든 것은 NPM 다운로드 계수가 소프트웨어 패키지의 인기 정도에 대한 통찰을 제공하는데 도움이 되지만 그렇지 않다.
비록 악의적인 참여자(예를 들어 나)의 가능성을 소홀히 하더라도 대량의 등록표와 캐시 실현은 이런 통계 데이터를 그다지 유용하지 않게 한다.

'인기'.

다행히도 NPM은 바람직한 점이 하나 있다. 바로 인기 통계!다운로드 계수 대신 더 유용한 통계 데이터를 사용하자...정확했어
아니, 인기 통계는 위장 다운로드 통계인 것 같다.아래에서 보듯이 제 패키지는 인기가 많습니다@prisma/engines.

다음은 두 소프트웨어 패키지의 빠른 비교입니다.
@prisma/엔진
이것은 자성의 문제이다
매주 다운로드
~100,000
~800,000
별.
264
0
포크.
35
0
공헌자
26
1
사용자
이 가능하다, ~할 수 있다,...
절대

결론

만약 당신이 이번 토론에서 한 가지를 발견한다면, 그것은 다운로드 자체가 결코 유용한 지표가 아니라는 것이다.
비록 나는 NPM이 하나의 유행도 지표를 만들 수 있다고 의심하지 않는다. 이것은 가방의 많은 다른 속성npms.io을 모을 수 있다. 그러나 지금부터 나는 NPM의 다운로드와 유행도 지표를 신뢰하기 전에 더 많은 배경 연구를 할 것이다🕵️.
재밌었으면 좋겠어!만약 당신이 어떤 생각이나 댓글이 있다면 언제든지 아래에 놓거나 트위터에 연락 주세요 - 
면책 성명: 본문에서 표현한 모든 생각과 관점은 나의 것이다.