-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Badge request: deno.land version #9838
Comments
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
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/axios@0.21.1/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 |
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, If it has to be service based then it would be |
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 At https://jsr.io/docs/migrate-x-to-jsr it says
so I think this feature request remains valid. Simultaneously they are also publishing guidance on how to migrate from /x to JSR. So.. 🤷 |
They are just giving authors more options |
📋 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.
The text was updated successfully, but these errors were encountered: