Closed fwqaaq closed 6 months ago
Hi, just for context a decision to publish to an additional registry would likely be a decision for the entire unified ecosystem (unified, remark, rehype, retext, redot, mdx, micromark, syntax tree, vfile) and that wouldn't be a light decision. Probably requiring a formal RFC process.
I haven't looked to deep into JSR and to make an informed decision we would have to outline the changes required to do so and whether that's worth it in 400+ separate repositories. Luckily, we have our GitHub tooling which simplifies adding the same config files to all repositories. But the question is whether that would be enough.
Hi, just for context a decision to publish to an additional registry would likely be a decision for the entire unified ecosystem (unified, remark, rehype, retext, redot, mdx, micromark, syntax tree, vfile) and that wouldn't be a light decision. Probably requiring a formal RFC process.
Yeah, this is a indeed huge work. I suggest starting the packages that have no dependencies. Additionally, the packages related to remark are entirely ESM, which is very beneficial for migration.
As mentioned I doubt a big decision will be made in this issue. It will be more likely to gain traction if you submit a RFC and make a compelling case.
Yep, @Murderlon is right, it’s a big decision that affects 100s of projects. Closing here.
JSR is pretty interesting btw. The main problem I foresee is that we do use some Node APIs that don’t have JS alternatives such as fs
, we’d need to test in Deno too. And, it requires changes to types due to its “slow types” thing.
Hi! This was closed. Team: If this was fixed, please add phase/solved
. Otherwise, please add one of the no/*
labels.
Initial checklist
Problem
Bro, hope to be able to publish tools like the
remark
(remark-parse etc.) to the JSR repositry.Solution
Using GitHub Action: https://jsr.io/docs/publishing-packages#publishing-from-github-actions
Alternatives
https://jsr.io/docs/publishing-packages