Badgen.net: Bug in npm badges

[tunnckoCore]

Again. :D

@babel/core is cyan, but shouldn't be, because it is latest.

The cyan should be only if non-latest dist-tag is passed, no matter it is scoped or not.

[tunnckoCore]

Ooh, i see why that's became a problem. You set semColor which colors it cyan if "alpha/beta/canary", which shouldn't be that way.

No matter what the suffix is, we should be driven by the tag name. If it is latest be blue (or based only on version number), otherwise if not latest then cyan.

[amio]

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).

[amio]

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 :D

[amio]

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.

[tunnckoCore]

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

[tunnckoCore]

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.

[amio]

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.

[amio]

Ping @olstenlarck, PR #53 is still waiting 😂

Have I convinced you on this topic? Do you have any further thoughts?

[styfle]

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.

[tunnckoCore]

I don't have time recently, but i'm still definitely not agree. :D

Have I convinced you on this topic?

In short, no, it depends. That's why i'm saying that it should be "platform specific". It's platform specific what the badge should/would say. In case with the npm badge, i definitely don't like it that way with that cyan ;d

In general it not make sense for me.

[tunnckoCore]

I know the red build is bad and the green build is good but I'm not sure why the build failed

Same thing with the npm. I'm mostly sure that all the community is agree that latest is "good". Totally another thing and fault is that that Babel is going through transitioning and i'm considering that as mistake - that, to publish beta or rc or whatever on the latest tag. But that won't be the case with all packages.

I most cases, latest is the guaranteed and stable one, right? So, it should not matter what is the suffix, at least for me.

[styfle]

I'll add my 2-cents to this topic...

Babel is doing something really odd here.

They decided that version 7.0.0-rc.2 is not stable enough to be called 7.0.0 (rc stands for Release Candidate and you can see there have been several).

But they also decided it is stable enough to get installed if you run npm install @babel/core without a version since it will default to latest.

This is a tricky one because it depends on what the meaning of cyan is meant to convey.

• a dist-tag version other than latest?
• a non-stable version?

I would lean towards the second option which is how it works now.

[tunnckoCore]

a dist-tag version other than latest?

My thought was that, yea.

So there will be only 3 things, easy things:

• blue - "stable", latest
• orange - < v1
• cyan - the dist tag

[amio]

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().

[tunnckoCore]

Babel is specific case, that was said...

But i won't continue, cuz i'm seeing that other :+1: all the time, so i will fold that. ;/