Or package authors should start using scoped packages.
Instead of publishing as cross-env you publish as @guy/cross-env
That makes typosquatting harder, and can help give users some ideas of packages which are by the same authors.
NPM could help by allowing packages to be published both to the "global namespace" AND as a scoped package automatically. (In other words, always allow accessing any global package by it's scoped name)
I would rather have some GitHub integration in place, so I could `npm install github.com/someone/somepackage`, like Golang forces us to do, for example.
I don't do that for all packages automatically nowadays because there is this bizarre culture of people publishing different things to npm and GitHub. To npm they send only "built" files from ES7 to ES5-compatible mode, while to GitHub go only the unbuilt sources which will not run anywhere.
A solution to that would be for an automatic builder to be run on every `git push`. A third-party service, somehow, someone, somewhere. Travis CI, maybe? I'm waiting for someone to have an insight and solve this problem in these lines.
Npm has had github integration for a while now (and straight git integration). Depending on how they setup things, a repo with a good postinstall script will build once it gets pulled so you'll have ES5 compatible files in your node_modules by the time you are running your application.
Not that that's an ideal system, but it's an option for some packages.
That's what Composer (PHP package manager) does. All packages are scoped, no global packages exist. Not fool-proof, but it makes typo-squatting harder.
Instead of publishing as cross-env you publish as @guy/cross-env
That makes typosquatting harder, and can help give users some ideas of packages which are by the same authors.
NPM could help by allowing packages to be published both to the "global namespace" AND as a scoped package automatically. (In other words, always allow accessing any global package by it's scoped name)