Why are _project_ metrics included in the quality note?

[ericmorand]

I was looking at the quality metric of twing and was wondering why it is "only" 91% even though:

• The package is 100% covered
• The package depends on no vulnerable dependencies

And then I found this on your website:

Has README? Has license? Has .gitignore and friends?
Is the version stable (> 1.x.x)? Is it deprecated?
Has tests? What's their coverage %? Is the build passing?
Has outdated dependencies? Do they have vulnerabilities?
Has custom website? Has badges?
Are there linters configured?

I'm not sure I understand what the .gitignore or linter presence has to do witth the package quality. It has to do with project quality - and even in this context it is debatable and opinionated - but by no means with the package quality.

What is published to npm are packages, no projects.

Intrestingly enough, twig package has a quality rating of 97% even though their code coverage is not even published - and by experience as maintainer not even close to 100% - plus their build status badge does not work and link to a 404.

So: how can the quality metric be 97% when the metric is computed from 2 values that twig doesn't publish and / or don't honor: Has tests? What's their coverage %? Is the build passing?

So, what is the rational here?

Asked differently:

• what difference does it make for someone that use a package that the projet has a linter or not?
• how is having a code coverage of 100% less important for someone that uses the package than having a linter at the project level?
• how do you take coverage into account considering the diversity of the CI tools available? Twing project is using GitLab as CI tool and I'm not sure how npms-analyzer compute metrics from the pipelines that run there. I mean, is it parsing that kind of output, or does it guess based on something else? https://gitlab.com/eric.morand/twing/-/jobs/5669355264

I'd also like to remind that a LICENSE file is not mandatory per npm rules themselves: they are mandatory only when using a non-standard license. See here for reference:

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#license

If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one:

{
  "license": "SEE LICENSE IN <filename>"
}
Then include a file named <filename> at the top level of the package.