badges
Badge request: deno.land version
📋 Description
Deno ( https://deno.com/ )
🔗 Data
Public : https://redocly.github.io/redoc/?url=https://apiland.deno.dev/~/spec#tag/registry/operation/getModule
🎤 Motivation
I was shocked to not find any issues / discussions about the
seemingly missing Deno package version badges, so here we are.
Just like NPM packages, Deno package versions should be displayable as badges. All the same reasons as to have NPM badges apply here as well. Deno isn't a small new fringe project, so there shouldn't an issue in that regard.
Personally I just wanted to add it to my repository to display the latest version
so people didn't have to go to the registry page, just like I do for NPM packages.
I was shocked
OMG 😮
I suspect part of the reason why this may not have come up is that Deno's registry is a fairly "thin" registry. From https://deno.com/add_module
All modules on deno.land/x need to be hosted as public repositories on GitHub.com.
deno.land/x downloads and stores your repository contents every time you create a git tag. We only do this once for every tag. This ensures that the contents we serve for a specific version can never change.
Our service needs to get informed whenever a new tag is created. For this purpose we use GitHub webhooks.
Because there is a strict one-to-one mapping between releases on https://deno.com/x and GitHub tags, basically all projects can just use the GitHub tag badge as a proxy. Lets say I wanted this for fresh, I could use:
https://img.shields.io/github/v/tag/denoland/fresh?label=deno&logo=deno
or whatever.
Maybe that's why it hasn't come up.
That said, it seems like a reasonable badge to add.
Just one thing I would like to clarify:
Deno (the language) has package.json/NPM support. Also, you can just import a module from anywhere on the internet. For example
import * as lodash from 'https://raw.githubusercontent.com/lodash/lodash/main/lodash.js';
or
import * as axios from 'https://cdn.jsdelivr.net/npm/[email protected]/dist/axios.min.js';
is a valid deno import.
So "a deno package" is quite a broad concept.
Our badges almost alway relate to a service. So we have "NPM" badges and not "node module" badges We have PyPI badges, not "python package" badges, etc. Taking that into account, if I make an API call like https://apiland.deno.dev/v2/modules/fresh and report the latest_version: What is the name for this service? Is it "Deno Third Party Modules", deno.land, deno.land/x ? I'm a bit unclear what this registry is called.
What does the import resolving mechanism of Deno have to do with their registry?
I don't think it will do any good overcomplicating things,
when someone that uses Deno hears Deno module they
think of a module hosted on Denos registry.
If it has to be service based then it would be deno.land,
or how it's generally referred to Denoland ( https://github.com/denoland )
An integration does need to relate to the service it fetches data for.
The only reason I bring up Deno's import system is because with deno (moreso than many other languages), a module that is being imported can come from lots of places so it seems even more pertinent in this case to be clear in the docs that this badge would show data about modules registered on deno.land, but not deno modules hosted in other places.
Quick bit of extra info on here. Deno recently launched another package registry: JSR I've created a tracking issue for that at https://github.com/badges/shields/issues/10007
At https://jsr.io/docs/migrate-x-to-jsr it says
Future support for deno.land/x
There are no plans to discontinue or shut down deno.land/x. Module authors can continue to publish and update modules there, and Deno code using it will continue to function.
so I think this feature request remains valid. Simultaneously they are also publishing guidance on how to migrate from /x to JSR. So.. :shrug:
it should be possible to migrate those modules to JSR with minimal changes.
They are just giving authors more options