badgen.net: Bug in npm badges

Babel is specific case, that was said…

But i won’t continue, cuz i’m seeing that other 👍 all the time, so i will fold that. ;/

Consider @babel/core’s case, I think latest doesn’t always mean “stable” or “best” (maybe “recommended”?).

In our cases, the cyan color doesn’t (shouldn’t) mean stable or unstable, just like the orange doesn’t say it’s unstable (we use a lot 0.x packages in production).

semColor() is meant to reflect semver’s convention:

• Orange => the MAJOR version is 0
• Cyan => the version has pre-release meta
• Blue => the version’s MAJOR > 0 and doesn’t include any pre-release tag, seems like stable.

If there’s a platform specific case, it should be handled in services’s live function, other than semColor().

Or another point of view about what the color means:

• Indicate the version number’s attribute, as a none strictly hint (‘v0.25’ may be a stable/latest version of some package, but we still give it an ‘orange’)
• Indicate the platform’s version strategy, like GitHub’s release/prelease, npm’s latest/next/etc.

Currently I choose the first one, it’s already used on current badges, it’s easier and simpler (no need to consider platform’s difference, hence platform independent), the semColor is mean to expand the idea (add ‘cyan’ color) and formalize this rule (make it an standalone util).

These are my thoughts on this 😄

People don’t know the line between yellow and green for install size, but it’s OK. That color doesn’t carry critical information, and we shouldn’t let it.

I would rephrase this: The color doesn’t carry exact information, only relative information.

• I know the red build is bad and the green build is good but I’m not sure why the build failed
• I know the yellow install size is larger than the green install size but not sure what the threshold is

In short, the color is a way to make one repo standout from another because something information is different and there’s a threshold triggering this color.

I see we have different demanding for badge color’s purpose.

I think badge color should not hold critical information, which will force people to read doc or guess it’s meaning (most people will do). Badge color is mean to give people a faster impression of it’s content, it’s a representation of it’s content, a helper for understanding.

All badges follow this rule, like green for build success, red for coverage 30%, or yellow for install size 14.3MB.

People don’t know the line between yellow and green for install size, but it’s OK. That color doesn’t carry critical information, and we shouldn’t let it.

I hate to procrastinate my job for tomorrow but that’s what happened… ;/ I had better thoughts back then… Anyway.

It should be platform specific. NPM’s latest is same as Github’s release, no matter what version says. It is considered “stable” if it is in latest.

Color (should) indicate and hint people to know if it is in dist-tag (in case of Github in prerelease stage) or not.

Color should not indicate if it has some specific word in the version/subject, it’s already visible that it has -beta.0.0.0 or -canary or whatever.

I’ll make my thoughts and notes later, but in short i’m not agree.

With this color indication, we can further remove @canary in subject text, wouldn’t it be a win?

Changed my mind, the label express the “intention” to show canary, not the result being canary.

I understand your point, but I still think v2.0.0-beta.0 is a beta version, cyan indicate this information(if the version is beta/alpha/canary). It doesn’t concern the platform specific info(latest from npm, or prerelease from github).