package-lock.json doesn't do anything for security unless you're going to walk the upgrades of each transitive dependency before you run `npm upgrade` (since each dependency can run arbitrary code while installing). So I wouldn't say it solves any of the security issues, just gives you a commitable snapshot of your deps.
One of the many things the npmjs.com website needs to do is provide a code viewer for each version of a package. It's a bit annoying that you have to unpack a tarball just to see the code you're going to be running if you install it. Right now everyone just takes for granted that if a NPM package links to a Github repo, that that's the code you're going to be executing.
Nothing is going to solve the explosion of transitive deps though without some sort of cultural change. I don't see that ever happening. I do like the ecosystem of tiny libraries but it's too large of a trade-off for security sensitive applications imo.
One of the many things the npmjs.com website needs to do is provide a code viewer for each version of a package. It's a bit annoying that you have to unpack a tarball just to see the code you're going to be running if you install it. Right now everyone just takes for granted that if a NPM package links to a Github repo, that that's the code you're going to be executing.
Nothing is going to solve the explosion of transitive deps though without some sort of cultural change. I don't see that ever happening. I do like the ecosystem of tiny libraries but it's too large of a trade-off for security sensitive applications imo.