jsr-io
Disallowing HTTPS imports is overdefensive
JSR has the notion of supported runtimes per package, thus disallowing HTTPS imports in packages that only supports Deno and browsers doesn't make sense.
HTTPS imports are free from all the black magic (i.e. rewrites) done by JSR, and quite a few people (especially Deno users) would want to avoid the need of transpiling or import maps to make their libraries work in browsers, so it should definitely be supported.
@lucacasonato This issue is not a question but a change request. If the JSR team have no plan to lift the restriction, they simply blocks JSR from being adopted by those who prefer HTTPS imports.
In my opinion, the current way of dependency deduplication is a big mistake. There might be pros but the cons is rather critical. Forcing that black magic for every library sounds like another version of the dependency hell to me.
Even if HTTP imports were allowed, transpiling would still be required to make it work in the browser as many dependencies on JSR are written in TypeScript and served as TypeScript to the client.
Even if HTTP imports were allowed, transpiling would still be required to make it work in the browser as many dependencies on JSR are written in TypeScript and served as TypeScript to the client.
While this statement is indeed true for browser, since deno supports them there is no reason to arbitrary block the publishing of https imports dependencies. There's some case where the npm package still don't work on deno, and you're stuck with either the esm.sh / deno.land version (e.g. esbuild for deno deploy)
The fact that's it not even a jsr check (you can trick the deno publish by using a non-statically analyzable import to bypass it) but hardcoded in the deno runtime (see https://github.com/denoland/deno/blob/14e406498672e7b8fbbfbcb7a057f798358909b4/cli/module_loader.rs#L859-L863) and still throws if your package is published on jsr is what pains me.
This is a case where it should be handled by the deno permissions system to decide whether imports are blocked or not, especially since we have the --allow-imports flag now, rather than being an arbitrary decision
If it makes the package incompatible with browsers or other runtime, then the maintainer should just update the compatibility section on their jsr package page, not being unable to upload their package
If the URL always returns the same content now and in the future, then you can vendor the import. I guess the only reasonable way to change JSR would be for the registry to vendor URLs upon publish. Doing this manually makes the whole step more explicit (which is both good and a bit annoying).
Even if HTTP imports were allowed, transpiling would still be required to make it work in the browser as many dependencies on JSR are written in TypeScript and served as TypeScript to the client.
NOT true, they can use: es-module-shims to directly use TypeScript in the browser, see: https://guybedford.com/es-module-shims-2.0 Hope one day we don't need the shim anymore to use TS inside the browser...
