Deno.land releases have stopped ~3 years ago
Zekromaster opened this issue · comments
Currently, the latest version of Ramda available on deno.land is 0.27.2, which was pushed around 3 years ago. From what I can gather, ramda on deno.land is actually a mirror of a repo by the apparently abandoned functional.land project, and as a result deno.land/x/ramda refers to functionalland/ramda as upstream instead of here.
Is there any hope of either:
a) The deno.land releases being somehow fixed to refer back to this repository? (Admittedly, I don't know what deno.land/x's policy even is for something like this)
b) A new module name being claimed on deno.land referring to this repo (i.e. deno.land/x/ramdajs)
c) The README fixing the deno.land imports to refer to more recent versions, since Deno is able to import from arbitrary URLs - i.e. just use jsdelivr's GitHub functionality
?
I was looking into this just now and came to the issues page to submit this very thing when I saw you beat me to it 🤣
The MR that added mod.ts and egg.js was #3054 submitted by @sebastienfilion, who also owns functionalland/ramda. From what I can discern, that fork was publishing to deno.land in leu of ramda/ramda doing it until that MR was merged. However, this repo never actually took over doing that.
@kedashoe What exactly is the release process? I know you've been doing it, but how? I see a scripts/prepublish, but not publish. And there is not github workflow either
Aside from npm I see jsdelivr is updated too, so that's good. There is a bower.json (lol) in the project, I'm pretty sure we can remove that
which uses https://github.com/davidchambers/xyz
Ack! I missed the Makefile in the root dir. Ok so xyz does npm publish, so what about jsdelivr? The release strategy of ramda ties in very well with Gitflow. We could make develop branch, have MRs go into that, and automate releases on master with Github Actions. Even make develop release a beta npm tag. That's how I have it over on ramda/types, but without the automation. I keep telling myself I'm going to get that setup but never have the time and keep doing release there manually as well
fwiw I would rather not use github actions, it is already automated bar running a single command. And it is so much easier to update/debug/etc running everything locally
Ok so maybe jsdelivr is automated with that prop in package.json in some way via npm publish. I'm not familiar with jsdelivr myself. Aside from open source publishing to npm, I'm most familiar with internal Artifactory instances for packages and Gitlab for container registries
And it is so much easier to update/debug/etc running everything locally
lol yeah that's always the worst part of it. Having a main/develop develop do have a beta or canary npm tag would be handy though
Jsdelivr basically just mirrors npm and GitHub. So "switching" to it would just be a matter of updating documentation to refer to jsdelivr instead of deno.land.
In my project I have "ramda/": "https://cdn.jsdelivr.net/gh/ramda/ramda@v0.30.0/" in my import map, which basically lets me just take the mod.ts from here, same way it worked with deno.land/x/ but using this repo as the base.