remarkjs / remark

markdown processor powered by plugins part of the @unifiedjs collective
https://remark.js.org
MIT License
7.66k stars 358 forks source link

Publish packages to JSR #1307

Closed fwqaaq closed 6 months ago

fwqaaq commented 6 months ago

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

Murderlon commented 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.

fwqaaq commented 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.

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.

Murderlon commented 6 months ago

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.

wooorm commented 6 months ago

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.

github-actions[bot] commented 6 months ago

Hi! This was closed. Team: If this was fixed, please add phase/solved. Otherwise, please add one of the no/* labels.