After thinking about JSR, still question ... WHY ?!

[redradist]

I understand that it is superset of npm, but on previous versions of Deno it was also possible to manages versions of package using just urls and version like it was done in deno.land/x

For example:
https://deno.land/x/astral@0.3.5
https://jsr.io/@astral/astral and install using deno install @astral/astral@0.4.8

For me it looks the same !! It is path backward ?!

Also moving Deno std library completely to jsr - looks like for me again path backward, why not publish in both places deno.land/x (for those who love to use url based libraries) and jsr (for those who came from npm ecosystem)

Maybe I do not understand something, please explain then ...

[redradist]

For now I see maybe one thing that makes jsr better than deno.land/x, is that not all links on deno.land/x could be reachable (for example author delete repository and forget to delete package on deno.land/x) ...

Maybe than jsr is self-hosting reliable deno.land/x, but why not provide in jsr simple url for accessing package ? Or maybe 2 interfaces, deno add (for depelopers from npm) and access by url for "native" Deno developers ?

[marvinhagemeister]

Problems with http imports:

• Diffused trust model: No guarantee that third party domains stay up. We received several security reports over the years where a domain changed ownership
• No way to de-duplicate dependencies. If two dependencies each pull in a shared dependency, like dep-A importing shared@1.0.0 and dep-B importing shared@1.0.6 you'll always end up with two copies of shared. This breaks lots of popular libraries like react. Also means that it's difficult to update a sub-dependency if it's imported by many other dependencies and keep them in sync.
• No way to use an import map in a library.
• No package boundary, meaning LSP will display every type from every file, even if a library intended it to be internal. Autocompletion is often useless for that reason if you're working on a bigger project with many http dependencies.

Advantages of JSR over http imports:

• Full proof of publishing through provenance attestation
• Libraries can use their own import maps and have it work out of the box
• Proper semver de-duplication, no more duplicated dependencies if version ranges match
• No more noise in autocompletion, you'll only see the types intended to be used
• automatic docs generation (nice touch mostly)
• Code on JSR can be pulled into other runtimes too, not just Deno.

We've written a bunch of blog posts on this topic which might interest you:

• https://deno.com/blog/http-imports
• https://deno.com/blog/jsr_open_beta
• https://deno.com/blog/std-on-jsr

[redradist]

@marvinhagemeister Now I think one intersting idea ...
What if during development and deploy, deno will provide "locked" import-maps for dependecies ?

For example we have the following import-maps.json or deno.json:

{
  "imports": {
    "@luca/cases": "jsr:@luca/cases@^1.0.0",
    "cowsay": "npm:cowsay@^1.6.0",
    "cases": "https://deno.land/x/case/mod.ts"
  }
}

and deno will introduce some command like deno lock imports and this command will generate the following import-maps-lock.json that could be reused in browser without need to use of deno bundle command:

{
  "imports": {
    "@luca/cases": "https://jsr.io/@luca/cases/1.2.0/mod.ts",
    "cowsay": "<local-path-to-npm-cowsay>/1.7.0",
    "cases": "https://deno.land/x/case/mod.ts"
  }
}

What do you think ?

[marvinhagemeister]

Well known locations are brittle for module URLs. You never know what part is the registry and what is the package. Like with https://example.com/foo@1/foo@2 Is the package foo@1 or foo@2?

Our experience over the past years with http imports has shown that third party domains get taken over by different entities leading to security issues. We cannot have that in the Deno ecosystem.

No, you cannot use http URLs for JSR directly. Doing so would break the module boundary and package import maps. What Ryan means there is that we download files instead of one big package tarball like with npm.

What you're describing with "locked" import maps is basically what we do with deno.lock. There is no spec for nested import maps in the browser though. There is a proposal that's being worked on, but it's far too early to adopt and unsure if it will ever succeed.

[redradist]

@marvinhagemeister

What you're describing with "locked" import maps is basically what we do with deno.lock. There is no spec for nested import maps in the browser though. There is a proposal that's being worked on, but it's far too early to adopt and unsure if it will ever succeed.

No, deno.lock is not the same what I propose !
Here part of deno.lock that I generated:

"specifiers": {
    "jsr:@std/http@*": "1.0.8"
},
"jsr": {
    "@std/http@1.0.8": {
        "integrity": "6ea1b2e8d33929967754a3b6d6c6f399ad6647d7bbb5a466c1eaf9b294a6ebcd"
     }
},

Instead I propose to generate additional deno-import-maps-lock.json:

{
  "imports": {
    "@std/http": "https://jsr.io/@std/http/1.0.8/mod.ts",
  }
}

[BlackAsLight]

What if I want still to use urls even with jsr, could you on site of jsr also provide this redirect url ?
For example I do not want to use "jsr:" specifier because it is not browser compatible and also do not want to use extra step deno bundle for bunding it to single .js file with all "jsr:" specifiers resolved ...

Even if you could and did use http imports from JSR, it wouldn't work in the browser as JSR would be serving TypeScript files, which isn't compatible with the browser.

Our experience over the past years with http imports has shown that third party domains get taken over by different entities leading to security issues. We cannot have that in the Deno ecosystem.

An example of this is with what happened with the polyfil lib. The domain expired, somebody else bought it and changed it to serve malware instead to millions of users browsers.

[redradist]

@BlackAsLight

What if I want still to use urls even with jsr, could you on site of jsr also provide this redirect url ?
For example I do not want to use "jsr:" specifier because it is not browser compatible and also do not want to use extra step deno bundle for bunding it to single .js file with all "jsr:" specifiers resolved ...

Even if you could and did use http imports from JSR, it wouldn't work in the browser as JSR would be serving TypeScript files, which isn't compatible with the browser.

Yes, it will not work on browser without compilation, but original idea to use import for production would be live.
I very like idea of using imports, but as was mentioned previously on this disscution, raw import could not support multiple versions like other package manager.

That is why I think it could be possible to bring ideas from both side, use "jsr:" during development, but on production allow to use raw imports by generating deno-import-maps-lock.json

[redradist]

@marvinhagemeister
Oh my !!
Looks like you removed deno bundle in Deno 2.0 ... (

My opinion, it should not be done even thought deno bundle (default one) was not ready yet, what instead should be done is SOLID principle.

I would use 'O' - Open-Close principle, leave deno bundle (with default behavior), but also add possibility to configure external bundlers, for example:

deno bundle main.ts # Default deno bundler

deno bundle --set-bundler esbuild # Deno start using esbuild bundler and start searching esbuild customization scripts
deno bundle main.ts # esbuild bundler

deno bundle --set-bundler webpack # Deno start using webpack bundler and start searching webpack customization scripts
deno bundle main.ts # webpack bundler

[marvinhagemeister]

The bundler in Deno had been unmaintained for years and it's too expensive to maintain for us. We removed it for now, but we are considering bringing it back at some point. The plan is to base it on rspack or rolldown if that happens instead of writing our own bundler.