The ability to fork and gain control if necessary is one of the main reasons one wants open source in the first place. So fork it.
Other than that: I find the microdependency / mass dependency trend in NPM very irritating. As a rule of thumb I think you should be able to know at least roughly all your dependencies + transitive dependencies and take some care that they're healthy projects. If you can't name them all - you probably have too many of them.
I think the problem with forking is you can't take the 'lodash' noun on NPM. So you make a fork of lodash, fix the outstanding issues - but getting every single dependency to actually accept it is a whole 'nother mission. And as long as the original project 'owns' that noun, this is true for everyone.
Does npm have a facility to say a package provides another? Would npm resolve that? Or at least accept that if I have package lojack-mine and it "provides:lojack" then this dependency is resolved?
Yup, you got it; the migration/reclaiming of package names is pretty key here.
One tricky aspect of the 'metapackage' approach (where, for example, hypothetical 'lodash-legacy' or 'lodash-ng' packages could both fulfil a 'lodash' dependency slot) is that someone needs to be responsible for determining which packages can fill which slots.
In cases where the package alternatives are close forks and API-compatible, that's easier to agree on - but in a large ecosystem, the solution needs to scale in terms of human and machine review time, while also providing a good level of trust to developers when they are selecting or migrating dependencies.
There are likely to be some tricks to reduce the assessment workload required in each case -- running test suites from the 'original' package and applications which rely on it against each candidate, for example -- but ultimately either the package maintainers, the community, the NPM organization themselves -- or some mix of all of the above -- have to determine the packages that could fulfil each slot.
Good packaging is hard, and it's maintenance work rather than green-field development. We (collectively) really should incentivize and fund it more, and ideally learn from and credit existing solutions.
I'm sure there are people who enjoy reviewing (and automating review of) packages, knowing that they're improving code quality and performance for huge numbers of developers. And similarly, there are plenty of developers who provide useful feedback on package quality by reporting bugs, running benchmarks and writing qualitative comparisons.
To guess at where we may be heading in the near-term: a pure Microsoft-subsidiary ecosystem is developing in this area -- GitHub and NPM provide all the data and infrastructure to host, scan and gather user feedback for the processes mentioned above.
I think they'll collectively do a good job, although any approach does take time to build and deploy. I imagine it'll also raise longer-term questions around the governance of open source software development and what role Microsoft would like to take in that.
On a more abstract level the problem space relates to network effects and influence goals. Microsoft believes that the open source developer community is either here to stay, or is here at least for a sufficient duration of time for them to be important -- and it would like to provide influence and guide rails to that community.
> If you can't name them all - you probably have too many of them.
Well, I want a unicorn, too. That is simply not feasible for anyone using any common javascript/node frameworks - many people's builds started failing with literally thousands of `npm audit` failures, even when their direct dependencies were relatively small.
Github/Microsoft just bought NPM, I really hope they are able to add some features that make it easier to specify different resolution algorithms when pulling dependencies so it's easy for any individual to apply a patch up-and-down the dependency chain, even if the main project hasn't been updated.
It should be enough to know your direct dependencies.
The problems that can be caught by knowing transitive dependencies but can't be caught by knowing direct dependencies, are rare.
Perhaps open projects could make a pledge of some sort that guarantees important properties as long as all dependencies also commit to the same pledge.
Other than that: I find the microdependency / mass dependency trend in NPM very irritating. As a rule of thumb I think you should be able to know at least roughly all your dependencies + transitive dependencies and take some care that they're healthy projects. If you can't name them all - you probably have too many of them.