Add [npm] badges for collaborator count and dependency version #2461
Conversation
paulmelnikow
added
the
service-badge
|
paulmelnikow
force-pushed
the
new-npm-badges
branch
from
224edce
to
e385907
Compare
| @@ -33,15 +41,15 @@ module.exports = class NpmBase extends BaseJsonService { | |||
| if (withTag) { | |||
| return { | |||
| base, | |||
| format: '(?:@([^/]+))?/?([^/]*)/?([^/]*)', | |||
| // The trailing optional means this has to be a regex. | |||
| format: '(?:(@[^/]+)/)?([^/]*)/?([^/]*)', | |||
There was a problem hiding this comment.
Have moved the @ inside the capture group to harmonize with the pattern.
|
Hey @calebcartwright, how would you feel about reviewing this PR? I've been writing a lot of code so there's a bit of a backlog to review. It'd be great to have this kind of help from you! (Also, no pressure!) |
|
@paulmelnikow happy to help, will do! |
|
Awesome 😄 Added: Feel free to DM me in Discord if you have questions! |
| @@ -20,6 +24,10 @@ const schema = Joi.object({ | |||
| Joi.alternatives(Joi.string(), deprecatedLicenseObjectSchema) | |||
| ) | |||
| ), | |||
| maintainers: Joi.array() | |||
There was a problem hiding this comment.
First thought I had here is about the usage of maintainers vs. collaborators key. I've seen both used before although I'm honestly not sure what difference they have to npm. However, if we're going to use maintainers here would it make sense to use maintainers instead of collaborators for the service and path name?
There was a problem hiding this comment.
The API uses maintainers, so in the schema we don't have a choice.
The npm website uses Collaborators:
I figure they've updated their terminology but did not modify the API, which is why I went with collaborators.
|
|
||
| const collaboratorColor = colorScale([2, 3, 4, 6]) | ||
|
|
||
| module.exports = class NpmCollaborators extends NpmBase { |
There was a problem hiding this comment.
Same comment as above in base service about consistency between maintainers + collaborators
|
|
||
| const keywords = ['node'] | ||
|
|
||
| const collaboratorColor = colorScale([2, 3, 4, 6]) |
There was a problem hiding this comment.
Low bus factor is good, but I'm not totally convinced on trying to devise an absolute scale of what number of collaborators is 'good' or 'bad' and applying that to all projects regardless of the size of their codebase or community.
I think its reasonable to say only one maintainer is bad (and so is zero) for all projects, but maybe just report the number in blue for everything >1 ?
There was a problem hiding this comment.
Part of my use case is discerning the size of the community, so it’s a little chicken and egg. I can see your point that we’re not in a position to say that 4 is too few or 6 is enough, and that the expectation of what’s good would change for widely used tools.
1 is bad. Should 2 be caution? (Maybe orange or yellow.) Keeping in mind a badge this administrative is less likely to be used on individual readmes than on organizational badgeboards or project comparison scorecards tracking a large number of projects.
There was a problem hiding this comment.
1 is bad. Should 2 be caution? (Maybe orange or yellow.)
Yeah - that sounds reasonable. 👍
|
btw, cheers for reviewing @calebcartwright |
This adds a badge for collaborator count. When evaluating a library, it can be useful to know that there's not a single-contributor bottleneck for publishing. Having more than one collaborator is a sign of library maturity.
It adds another badge for dependency version of published dependencies, which solves a similar problem as the node-version badge. I will find this useful for making sure dependencies are up to date in a library.
There are lots of possible refinements here:
It also updates the base service to use a pattern instead of a regex, in the case where that's possible. Hopefully the other one will be possible after the fix in pillarjs/path-to-regexp#173.