I am not a user of Deno, but I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM. Was it revised at some point that a package repository is needed? What's the back story?

HTTPS imports will continue to work and be supported in Deno. However, as we observed their usage in the wild, a couple problems became clear:

1.) Duplicated dependencies - projects would often download multiple versions of the same dependency, because there was no deduplication happening based on semantic versions.

2.) Disappearing dependencies - under some circumstances, an HTTPS import URL would be unavailable, causing code dependent on these modules to break.

A central package repository could solve for both of these problems. We considered (and very nearly chose) to just use npm, but it introduced functional and UX problems we wanted to solve for users. So we set about building JSR, and did so in a way that wasn't tightly coupled to Deno (JSR didn't need to be - it is useful in the context of any JavaScript runtime).

> a couple problems became clear: 1.) Duplicated dependencies

I’m sorry but that did not come up when designing the system? It’s the whole principle of semver ranges that deno decided to do away with. I cannot believe nobody saw this as a drawback. It’s the first thing I thought when I saw hardcoded versions.

This is a solid reason to build it. Makes sense to me.

In case you are not aware (maybe you are) node has experimental support for http imports. I personally think this feature is a disaster for many reasons, but if you want to use it in your toy apps it is there in node.

> I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM

I am imagine most Deno users considered this a weird wart or foot gun, the rest of deno looks interesting.

I’m curious what this means in regards to this existing “use Deno to also publish to npm” workflow (https://deno.com/blog/dnt-oak) which I was considering using, and then the JSR announcement happened.

The thing I like about the blog post and the mentioned dnt tool is it takes care of lots of bullshit you otherwise need to figure out when publishing to npm.

What is the relationship between JSR and DNT in this case? Should one be used over the other? Together?

If I want to publish a module so it’s available for Deno and NPM, what is the recommended approach now?

As JSR develops, you can expect to see more features like those of dnt start to show up in the npm compatibility layer. We've also been exploring how to create a good DX around simultaneously publishing JSR modules to npm, so publishers can control their namespace there as well. We definitely know it's a usage pattern folks are interested in.

In the immediate term, dnt is still a very strong choice for people that want to develop modules in TypeScript using Deno, and then publish them to npm. In the fullness of time, I expect that JSR will provide a pretty complete solution to this problem as well.