Add the discord.js to JSR

[pedronicolasg]

List discord.js on JSR. This would simplify package management for Discord bot developers and increase the library's visibility.

[Legends-of-NGDB]

Good idea. I visited the website, and the style is better than npm. Discord.js team should really do this.

[NickantX]

That’s surely a lot of buzzwords. But no actual advantage for discord.js itself is mentioned… apart from visibility but let’s be honest here: you wouldn’t go to jsr, see discord.js and then decide „oh; I could make a discord bot“. It‘s usually the other way around.

I do agree here. I will say one nice thing about jsr is it's more common to publish typescript source files to it, which makes using go-to-definition in IDEs to see how something works nicer than most npm packages. But since the core library isn't typescript, this advantage isn't present.

[pedronicolasg]

Fair points @NickantX and @Qjuh , but JSR offers more than just visibility. Its native TypeScript support makes navigation and go-to-definition smoother for developers, even if discord.js core isn’t TypeScript. Plus, JSR's modern approach to package management addresses dependency optimization and security, offering a better developer experience overall. It’s not about replacing npm but providing an alternative that aligns with modern workflows and future trends.

[vladfrangu]

I will give my two cents, in no particular order...

• theres still a lot of buzzwords just thrown around about JSR. We can always publish TS sources to npm too, we're choosing not to (for better or worse is to be decided)
• Publishing to JSR would be nice, and if someone were to PR support for it, sure, but it's not a current priority
• I'm not sure how JSR addresses anything about dependency opt or security, can you link us some resources about this? 🙏
• Support for JSR for anything outside deno is to use some CLI to add the dependencies from JSR through npm, and if we are talking about security... that ain't good imo

[pedronicolasg]

I will give my two cents, in no particular order...

• theres still a lot of buzzwords just thrown around about JSR. We can always publish TS sources to npm too, we're choosing not to (for better or worse is to be decided)
• Publishing to JSR would be nice, and if someone were to PR support for it, sure, but it's not a current priority
• I'm not sure how JSR addresses anything about dependency opt or security, can you link us some resources about this? 🙏
• Support for JSR for anything outside deno is to use some CLI to add the dependencies from JSR through npm, and if we are talking about security... that ain't good imo

Thanks for sharing your thoughts! You’re absolutely right that TypeScript sources can totally be published to npm too. That said, JSR does have some interesting benefits that make it worth considering.

On dependency optimization, JSR uses ES modules (ESM) natively, which skips the whole node_modules mess and makes dependency resolution a lot cleaner and more predictable. It also supports import maps, which help simplify imports even further.

For security, JSR benefits from Deno’s approach, where packages don’t get unrestricted access to the system by default. That’s a nice layer of protection compared to traditional package managers.

I get the point about needing a CLI to pull dependencies outside of Deno, that’s definitely not ideal yet. But I think early adoption could help push for improvements that make it smoother for everyone in the long run.

Here are a couple of links with more details if you’re curious:

• Introducing JSR
• Deno's Security Model

[Wissididom]

To me, this sounds more like a reasoning for using Deno instead of a reasoning for using JSR or rather publishing to JSR.

On dependency optimization, JSR uses ES modules (ESM) natively, which skips the whole node_modules mess and makes dependency resolution a lot cleaner and more predictable. It also supports import maps, which help simplify imports even further.

You can totally use discord.js as ES module in Node.js (which is what I do in all of my bots, that are still using Node). Afaik, JSR just doesn't allow CommonJS (except for the packages dependencies). Also, if you use Node.js, you will have the node_modules folder no matter if you use ES modules or CommonJS. That is rather a question of the runtime you are using.

For security, JSR benefits from Deno’s approach, where packages don’t get unrestricted access to the system by default. That’s a nice layer of protection compared to traditional package managers.

That also sounds rather like a Deno thing. I don't think the permission system will get used in Node.js if you use npx jsr add discord.js or similar. Of course that might be true, if you use Deno, tho.

Regarding the links, the Introducing JSR one isn't really helpful, I think, because that seems to just be the homepage of JSR and no specific page that explains JSR in detail including the advantages and disadvantages and the second link doesn't even have to do with JSR, but is rather a link for Deno's security/permission system.

TL;DR: I think the message from about 35 minutes ago is mostly about Deno, and not about JSR.