Comment by vorticalbox

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.)

I don’t consider them a problem at all. It’s how browsers have worked for a long time.

My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction.

Personally I would have like deno it stick with url imports and not added the npm support.

Ryan set out to “fix” his mistakes with node only to fully embrace them again.

Annoying to update instead of a package.json, which they now have an equivalent of, realizing their mistake.