dependabot-core
dependabot-core copied to clipboard
dependabot
Support deno
Registry v2 was released 2 days ago. Now deno/x/ requires proper versioning in modules, has an API and simplifies the distribution with their own cdn which should help in adding support for it in dependabot.
See deno-udd for reference on how the community already update their deps.
If dependabot were to support Deno, I don't think only deno.land/x should be supported. nest.land, raw.githubusercontent.com, and other popular registries / hosts should be supported.
Currently have a dependency-checking script for deno.land/* dependencies. Looking at ways to get latest version for other hosts. Relies on unstable Deno functionality.
https://github.com/legowerewolf/deno-dependency-checker
Edit. Kinda wish I'd known about deno-udd before this.
recent updates to Deno Language Server might be of help here
and hopefully support will arrive in the following months from esm.sh, Skypack, JSPM, etc. too so that it won't be just deno.land/x, deno.and/std, etc.
https://deno.com/blog/v1.17#updates-to-the-deno-language-server
I think that there are two ways to support deno; import_map.json and mod.ts dependencies... I suppose that dependabot should only support import_map.json as it's a future-proof standard.
Any plans for supporting Deno in the future? Thanks!
Having looked through lots of projects trying to find a standard for my own, it looks like it's split between import_map.json, deps.ts and a hodgepodge of other dependency trackers or raw imports. I can see how this would be difficult to track and manage. That said, with as much as Deno has established itself in the development community it would be worthwhile to at least try to support either import_map.json or deps.ts (ideally both). I feel that if Dependabot can support Gradle (Java's top freeform dependency manager) that deps.ts should be a breeze, and that import_map.json is only a stone's throw from npm's package-lock.json.
It would be great to get a timeline on this, considering the issue has been open for over two years now.
I think we should consider relying on the more standardized deno.lock file (and optionally deno.json that specifies lockfile location), which if present will not only encode package versions but also their hashes, so Dependabot could even detect if the hash changed without changing the version.
Seems like new ecosystems are now welcomed from maintainers in https://github.com/dependabot/dependabot-core/commit/0f931f452e9e51a3996a010ca21c90115b7f80cf
Supporting import_map.json (and deno.json because it's a superset) isn't only Deno-specific. It would also help frontend apps that don't need a build step and only use vanilla HTML/CSS/JS. The only problem is the large number of various JS CDNs that would need to be supported.
Another feature that would be useful for Deno in particular is support for jsr: https://jsr.io/docs/using-packages
Given that other ecosystems directly shell out to the pm (as opposed to Renovate, which does it from scratch), I'd just shell out to molt, and let it handle it. It's worked great for my use cases, it's just not automated. On the other hand, it does have it's own competition (molt-action, though I haven't tried it), so maybe not worth it?
