Any plans on publishing Lume to JSR?

[yeskunall]

Right now, if I want to publish a package that depends on Lume to JSR, then it’s not possible. See here for an example:

deno publish --dry-run
Checking for slow types in the public API...
error[invalid-external-import]: invalid import to a non-JSR 'https' specifier
 --> /Users/kimchi/dev/remote/github.com/yeskunall/lume-umami/mod.ts:1:29
  |
1 | import type { Plugin } from "lume/core/site.ts";
  |                             ^^^^^^^^^^^^^^^^^^^ the specifier
  |
  = hint: replace this import with one from jsr or npm, or vendor the dependency into your package

  info: the import was resolved to 'https://deno.land/x/[email protected]/core/site.ts'
  info: this specifier is not allowed to be imported on jsr
  info: jsr only supports importing `jsr:`, `npm:`, `data:`, `bun:`, and `node:` specifiers
  docs: https://jsr.io/go/invalid-external-import

error: Found 1 problem

That’s because HTTP modules are supported in Deno, but not in JSR.

In the same doc they state that deno.land/x will not be discontinued of shut down*:

There are no plans to discontinue or shut down deno.land/x. Module authors can continue to publish and update modules there, and Deno code using it will continue to function.

However, by not publishing to JSR we miss out on their DX features, the 2 main ones (for me) being:

• Automatic API documentation generation from source code
• Zero-config publishing from GitHub Actions

*Personally, I have come to not trust these statements. They are akin to “forever” (end of time) or “unlimited” plans, which frankly, don’t exist. But that’s a me problem and I get that.

On top of that, deno.land/x has some concerns for which JSR was created, a big one being its lack of SemVer enforcement.

I’m opening this as a discussion to get the conversation started, but I understand if this is not a priority for Lume (as of yet).

As always, thanks for your work on Lume! 💖

[oscarotero]

Hi @yeskunall

There are no plans to move Lume to JSR, at least in the medium term, until some changes are made in JSR. I don't feel confortable with some of its design decisions.

• The exports key make the package not compatible with the filesystem and HTTP. I had to create this utility to minimize this issue. This key also make the JSR packages incompatible with standard ES modules (see this issue: [JSR] please allow removing exports from jsr.json, allow all files to be imported denoland/deno#28139)
• JSR is not compatible with import maps. You have more context here: JSR import maps denoland/deno#23504
• It's not easy to test a package without publishing it. Lume allows to use a dev version based on the commit hash. Even NPM ecosystem has something like this https://github.com/stackblitz-labs/pkg.pr.new
• Despite JSR claims to be "TypeScript first package registry", there are a lot of TypeScript features that don't work in JSR (JSX support, implicit types are marked as "slow types", etc).
• Dynamic imports in JSR are not fully supported. There are many issues with that, specially if you want to import local files (something that Lume does). I think it's not a good idea that JSR modify your code before publishing.
• It's vendor lock-in. Once you are in JSR it's not easy to exit. It's a non-standard centralized solution. For example, it's not easy to move your packages to a different instance in the future.

HTTP imports are a superior solution to me (despite their flaws, I know they are not perfect). They don't have any of these problems.

[yeskunall]

I really appreciate you taking the time to give your thoughts on this. I only asked because I was planning on publishing my Lume plugin to JSR, but now I’ll just push it to deno.land/x instead. It’s not a big deal.

HTTP imports are a superior solution to me (despite their flaws, I know they are not perfect). They don't have any of these problems.

I’m guessing you’re referring to this post. In a way, I agree with your statement. Outside of the reliability issues, most of the problems stated in that post seem to be about DX, not actual architecture (or design) issues.

[oscarotero]

I think reliability is not a problem in HTTP imports. Deno has a great permission system and by default it only allows to import modules from deno.land, esm.sh and jsdelivr. So it's easy to control and limit the origin of the external dependencies.

I think the main issue is the duplicated dependencies and probably it was the main reason why they created JSR. But this is a problem that could be mitigated with import maps, especially now that there's a standard spec for merging multiple import maps (it didn't exist when JSR was created, I don't know what would happen if the spec existed before).