Deno 2.8 - Hackdot

Re:Deno 2.8 by AgentME on Friday May 22, 2026 @04:17PM (#48241054)

One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.)

Also, if multiple dependencies of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.)

(Deno's current support for NPM and JSR avoids these issues.)

[ Parent | on HN ]

Re:Deno 2.8 by VerifiedReports on Saturday May 23, 2026 @02:37AM (#48245283)

Thanks. I use JSR and always pull in the latest, figuring that I'll lock it down when development is done.

[ Parent | on HN ]

Re:Deno 2.8 by AgentME on Tuesday May 26, 2026 @03:19PM (#48284601)

Your deno.json/package.json should generally pin things to their major version (eg. "^3.1.4"). Your application's lockfile (deno.lock/package-lock.json) which is generated by default pins your dependencies and your sub-dependencies to exact versions.

[ Parent | on HN ]

Re:Deno 2.8 by WorldMaker on Saturday May 23, 2026 @05:15PM (#48251597)

Deno always supported importmaps so dependency management was importmap management. If a script had its own dependencies it could depend directly on a URL or better yet it could use an importmap name and expect you to add it to your own importmap. Admittedly that was moving some of the work of a package manager to manual steps, though, so JSR is still an improvement over managing an importmap yourself for your entire dependency tree.

Also, URLs didn't have to mean "exact version". A script provider might use a URL scheme with exact versions in it such as `/packagex/2.18.3/main.js` or could do semver-floating symlinks like `/packagex/2.18/main.js` for latest patch and `/packagex/2/main.js` for latest minor. You could even have hosts that just used the classic top-level `/packagex.js` for whatever is the latest.

I think the real problem with URL dependencies wasn't so much "exact versions", it was the confusing flexibility that versioning schemes were dependent on the package host because URLs are orthogonal/agnostic to version numbering and different package hosts can do whatever they wanted. (Naming conventions you'd have to look up for each/every host versus semver-aware package management code.)

[ Parent | on HN ]