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:
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.
I was looking at the quality metric of twing and was wondering why it is "only" 91% even though:
And then I found this on your website:
I'm not sure I understand what the
.gitignoreor 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,
twigpackage 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
twigdoesn'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:
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