Well, based on what I read, he's not actually making the equivalent of npm. Instead, he's proposing a new tool ("dds") and new syntax of config files to integrate build and package management. This distinction is key because the "package manager" for javascript implies npm the the tool & package specification but also a public repository ("https://www.npmjs.com") that is funded by the Nodejs/NPM Inc entity.
Likewise, Rust's package manager points to "crates.io" repository which I believe is funded by Mozilla.
This blog article is not talking about making a C++ repository like "npmjs.com" and "crates.io". Only a syntax specification. Arguably, the destination repository (server) is more important than the command-line tool (client) because it's easier for a funded website with diskspace+bandwidth to justify the existence of a tool rather than the other way around.
> Did C++ not already have a fully featured package manager until now? Why not?
It's a seemingly simple question but it the "answer" which hasn't happened yet is complex and has multiple parts. The 2 big parts are (1) social inertia and (2) technical complexity
(1) social inertia: C++ created ~1986 has 2+ decades of usage before the idea of "let's have a process _automatically_ reach out to the internet to download dependencies" became popular. Thus, there is no well-known repository that became a Schelling Point[1] for C++ programmers to upload their C++ libraries.
Consider popular C/C++ libraries like SQLite, Zlib, OpenSSL, etc. Why don't those authors upload their libraries to a package manager repository? Because nobody made an influential website destination for it that everybody adopted. E.g. If Google Inc funded a C++ repo with disk space and bandwidth, would corporate politics prevent Microsoft and Apple from uploading their code to it? In contrast, the Javascript quickly adopted NPM that was funded by Nodejs and it was the already default baked into Nodejs downloads. Which entity in the C++ world is analogous to NPM inc to fund a repository that Google/MS/Apple/Adobe/etc would all adopt? It needs to be an entity that cuts across all those competitors. Maybe Intel? Or maybe Epic Games (they make Unreal Engine)? Or all the big competitors agree to contribute to a non-profit entity? Nobody has stepped up to the plate like NPM Inc did.
(2) technical challenges: C++ has a compile and link steps that interpreted languages like Javascript don't have. In npm, the assets are "text" (i.e. .js files like leftpad()). In C++, many library publishers (proprietary) don't offer source code (the "text") and only binary precompiled .lib files. These libraries are binary blobs that are incompatible across cpu architectures and compilers (Intel vs ARM, Microsoft MSVC vs gcc, etc). Because C++ is low-level, there's also a different set of build configs such as 32bit vs 64bit, static link vs dynamic link, and DEBUG vs RELEASE, etc. This means C++ needs to implement a much more complicated "dependency" syntax way beyond just "versions" and nobody has created that specification that everybody has agreed to use. Since Javascript doesn't have separate compile & link phases, something like "npm" is much easier to create. If Rust also has "compile & link" step, how did they successfully get people to adopt the "cargo" tool and the "crates.io" repository? Probably because Rust's ecosystem of programmers has more emphasis on shared "open source code" than the C++ programmers of the 1980s and 1990s. Also, we emphasize again that Rust's patron (Mozilla) also funded "crates.io" and Rust programmers just adopted it so the "cargo" tool has an http destination to point to download artifacts. There's no equivalent influential entity in C++ yet. In terms of package spec complexity, I haven't studied Rust's TOML configuration spec to know if it's flexible enough to handle all of the different ways that C++ practitioners build files. A lot of C++ build flexibility is put into "./configure.sh" scripts (e.g. ffmpeg, Qt, etc) so I don't know if toml spec is a superset of all that.