Skip to content
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

Publish packages to JSR #1307

Closed
4 tasks done
fwqaaq opened this issue Apr 10, 2024 · 5 comments
Closed
4 tasks done

Publish packages to JSR #1307

fwqaaq opened this issue Apr 10, 2024 · 5 comments
Labels
👀 no/external This makes more sense somewhere else 👎 phase/no Post cannot or will not be acted on

Comments

@fwqaaq
Copy link

fwqaaq commented Apr 10, 2024

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

@github-actions github-actions bot added 👋 phase/new Post is being triaged automatically 🤞 phase/open Post is being triaged manually and removed 👋 phase/new Post is being triaged automatically labels Apr 10, 2024
@Murderlon
Copy link
Member

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
Copy link
Author

fwqaaq commented Apr 10, 2024

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
Copy link
Member

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
Copy link
Member

wooorm commented Apr 10, 2024

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.

@wooorm wooorm closed this as not planned Won't fix, can't repro, duplicate, stale Apr 10, 2024
@wooorm wooorm added the 👀 no/external This makes more sense somewhere else label Apr 10, 2024

This comment has been minimized.

@github-actions github-actions bot added 👎 phase/no Post cannot or will not be acted on and removed 🤞 phase/open Post is being triaged manually labels Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
👀 no/external This makes more sense somewhere else 👎 phase/no Post cannot or will not be acted on
Development

No branches or pull requests

3 participants