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 acurrent 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

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 acurrent 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 usesES modules (ESM) natively, which skips the wholenode_modules mess and makes dependency resolution a lot cleaner and more predictable. It also supportsimport 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

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 thenode_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 usenpx jsr add discord.js or similar. Of course that might be true, if you use Deno, tho.

Regarding the links, theIntroducing 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.

This sounds more like a reasoning for using Deno instead of a reasoning for using JSR or rather publishing to JSR.

Fair point, I probably leaned too much into Deno comparisons earlier. My intention was to highlight some of the benefits JSR could bring, even for Node.js users, like native ESM support and avoiding thenode_modules mess. It’s more about offering an alternative package manager that feels modern and streamlined, not necessarily tied to Deno.

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.

Yeah, that’s a great point, it’s more about the runtime. I get that Node.js will still usenode_modules, regardless of whether it’s CommonJS or ESM. My suggestion to add discord.js to JSR isn’t to force a Node.js user to change how they run their bots but to give them another option that aligns with more modern development practices.

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.

Totally agree. Even though this security layer is more relevant to Deno right now, I think supporting JSR could encourage similar improvements for Node.js over time. It’s not about forcing anyone into that system, but the idea of stricter package security is definitely a step in the right direction, and I’d love to see it evolve.

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.

That’s fair, those links weren’t great, I’ll admit. I’ll skip linking and stick to explaining directly this time, which probably makes for a clearer case anyway.

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

Yeah, I see where you’re coming from, and I agree my earlier comment veered too much into Deno territory. I just wanted to bring up how JSR could offer something new for Node.js users too, things like ESM-native handling and tighter security aren’t tied exclusively to Deno. Hopefully, this clears things up and makes a better case for why publishing discord.js on JSR could be worth considering!

You cleared nothing up at all. You acknowledged that ESM native is already possible in Node.js independent of where the package is published. And you acknowledged that the security aspect didn’t apply to Node.js. So please enlighten me on

I just wanted to bring up how JSR could offer something new for Node.js users too, things like ESM-native handling and tighter security aren’t tied exclusively to Deno.

Because you keep on repeating the same buzzwords sounding like a salesman for that package repository or - even worse - an AI.