This isn't entirely fair to Deno but it always amazes me how people start out with "we don't need packages! Just do direct imports" and eventually end up with "okay fine fine here's a package manager". Packages are great! Don't dismiss them just because in edgecases they're bad.
In fairness, the two examples, Deno and Go, are successful projects, so maybe it's not a bad initial strategy.
Deno still won't have a package manager, at least in the style of npm. You don't need to learn a bunch of CLI and janitor a package.json file. You just add an import to your source code and you're done. Pulling in a npm package is the same as pulling in code from github, it's just a special URL. That's it... that's the 'package manager'.
Except that, as the ecosystem grows, you eventually have packages that are complex enough that they have imports, and those packages have imports.
And now because you've hard-coded imports at every level, you can end up with a dozen different versions of the same import, causing potential conflicts between the various components of your app.
Package managers evolved to be the way they are _because they're useful._ It's not like people said "let's add all of this complexity for fun!"
Direct imports failed as a solution for Go, and they already have been acknowledged as an incomplete solution for Deno (import maps are already a larval form of package.json, but without the ability to inherit child import maps, which means it's still broken, but presumably it will eventually be fixed).
Not having a standardized place where you can see the dependencies of a project, and not being able to distinguish which are _development_ vs _runtime_ dependencies, is also rather broken, and would require a package analysis tool that's far more complex than a package manager to use to trace the dependency tree reliably.
Its the same stuff npm does but it doesn't depend on npm's CLI. It sounds like you're mad they're moving the cheese a bit. IMHO I'm glad to be rid of the npm ecosystem baggage.
Package.json is a mish mash of a lot of concerns. It has project metadata, that's also duplicated in your readme and github descriptions. It has scripts, that are also probably just calling into other shell scripts and such in your project. It has your dependencies. It has your development environment setup. It has random key value pairs you decided to place there years ago and forgot the exact reason for now but are too scared to remove them. It's a royal mess of a file to manage.
Having a file to manage locked dependency versions isn't bad. Having a file that has grown into a crufty monster with millions of uses can be bad.
I don't care whether it's all in one file or in a dozen files, but I want all of that information to be available programmatically in a text file (unlike in a readme or on Github) in a standardized location in a project.
In that respect, package.json is a strict win. Your lack of willingness to use `git blame` to see why you added a line, or lack of reasonable git comments, is not to be blamed on the file.
Complexity is unavoidable. How could you write a tool like license-checker [1] for a Go-based project without having license information in a standardized location? Without the scripts section, how can you create a tool like husky [2] that automatically installs git hooks for a project? Every single part of package.json is there for a good reason; at best you could argue that putting some of it in other files would be aesthetically superior, but that's just bikeshedding.
Complexity isn't de facto bad. Some complexity is required if you want a certain level of functionality to become available. Deno (and Go) are slowly accumulating that "cruft" as people realize that those functions are actually useful or even critical to a mature ecosystem.
The dependency inspector is showing each TypeScript file, which strikes me as a newb mistake if I've ever seen one. That's just tons of unnecessary noise distracting you from what you need to know. Heck, it's also showing library files, which are going to be mostly irrelevant. If I include a framework that has 50 source files, I really just want to see what framework version I've included, not the place where every one of those fifty files are included every time they're included. Heck, if one indirect dependency had a bad version tag it would be nearly impossible to see.
The lock file format is also TypeScript-file based, which ... well, since dependencies can point at arbitrary git repos, you could easily end up in a situation where the version tag on the repo is changed and then you can't find the file you need to download. It's a pretty worthless lock file if the file can just disappear from the internet; a lock file should exist to guarantee that a package can be rebuilt exactly, not just prevent it from being rebuilt if it can't be rebuilt exactly, which is all the Deno lock does.
npm on the other hand will prohibit anyone from deleting an older version of a package if anyone else is using that package. "leftpad" can never happen again now in Node. Having a centralized repository is actually a Good Thing; being able to search through all the packages in one central repo and determine relative popularity of each is also useful.
Also: The lockfile is a generated shrinkwrap file. That's only a tiny piece of what I'm talking about. What I want to be able to do is set the exact version of an indirect dependency without needing to fork and rebuild every dependency. See yarn resolutions [1] for an example in the npm ecosystem.
No, I'm not mad because it's different. I habitually chase the bleeding edge up to and including jumping between frameworks and build systems and even languages and editors in constant search of ways to improve my development workflow. I thrive on learning new ways of doing things. I was enthusiastically digging into Deno shortly after they very first 0.x announcement, but quickly saw a number of showstopper flaws (including lack of npm compatibility) that caused me to write it off.
No, I'm complaining because Deno is missing crucial features. "Lack of features" isn't a feature on its own, especially when people use those features. (See also the Go language.) I also would miss the "scripts" section of package.json, since it's a centralized location for the various commands that a project might need; things like "generate a new migration file" or "run both the client and both servers" vs "run only server A".
This is all complexity that was swept under the rug by Deno and that will need to be replaced by community standards that won't be standard.
I'd still say Go doesn't have a "package manager". The dependencies are fetched, cached & built as you need it, but there's nothing comparable to "npm i"/"npm uninstall", dpkg/rpm/apk/etc, as such. If you want, you can just import example.com/foo/bar in your source, and the rest is just reproducability (version & hash) and caches.
Is deno successful? I (in my limited world) don't know anybody using it and don't see it mentioned in job descriptions etc.
And to comparing to other languages: It's not like "ok, projects became to big we need better package management" or something, but to me reads more like "there's too little deno stuff and migration prevents people from going here, so let's try to embrace the other runtime's stuff so maybe more people can use our runtime without having to start from scratch"
It's not even 5 years old, give it some time for people to pick it up and use it. Python was created in '91 but even by '96 it still wasn't widely used.
I think there's quite a big gap between success and being more popular than NPM. Plus it's only a few years old. Job adverts are usually several years behind what companies actually use and companies are behind what hobbyists use.
I'd say it is on a successful trajectory. The main issue with it was NPM compatibility so I think this is a very very wise move, even if it is pragmatic rather than ideal.
In fairness, the two examples, Deno and Go, are successful projects, so maybe it's not a bad initial strategy.