The history of modularization in JavaScript is a tedious one. ES Modules ("import") were introduced in 2015 and now seem to have broad support across different environments. But the precursor to ES Modules, CommonJS ("require"), is still widespread enough to require backward compatibility. And neither module system has an opinionated take on the actual package management (e.g., yarn and npm).
It seems that new languages are starting to converge on first-class language package manager as part of the spec. Rust has the crate build system and explicit module system. Go converged on first-class go modules. Both systems can be difficult to understand for beginners.
Languages used to be differentiated on their standard libraries – how much could you do without having to bring in any additional code?
In the future, I think that languages will be judged on how easily developers can share and reuse code.
Language designers often skip these parts because they aren't always hard technical problems. Documentation, module discovery, and developer UX often end up being just as important as compiler improvements.
Of course, languages have historically been decoupled from package management because it's hard to predict the workflows a language will need to support. Online/offline, client/server, trusted/untrusted, embedded, static linking/dynamic linking. But maybe we're converging on a generic solution that solves the hard problems.