This will be included in v7, and may require a fall-back lockfile to support cases where the user installs with --no-shrinkwrap or deletes the shrinkwrap file.

When you say a "fallback lockfile" do you mean like, a temporary npm install --package-lock --package-lock-only? That'd be great (and it's what would make npm audit work for this scenario as well).

@ljharb The idea would be a copy (or hard-link) of the lockfile at node_modules/.arborist-lock.json. It would not be authoritative during install (like a file at ./npm-shrinkwrap.json or ./package-lock.json would be), but it would give us a place to stash metadata whenever we change or read the package tree if the user is running with --no-shrinkwrap or --no-save.

That would also let us make things like npm ls and npm fund much faster, since we can be reasonably confident that bundled fallback lockfile reflects what's actually in the tree.

And yeah, it would make npm audit work even if there is no lockfile in the project root.

That sounds awesome, especially if npm install --save and friends iteratively updated it.

That sounds awesome, especially if npm install --save and friends iteratively updated it.

The idea would be that it gets updated even when --no-save is set. It'd be kept in sync 100% of the time, regardless of what we do (or don't do) to the package.json and package-lock.json.

I think the needs here are addressed by #90.

Basically, arborist will set npm_package_from, npm_package_resolved, and npm_package_integrity, for the package having its lifecycle script run.

I presume that will satisfy your needs?

Looks good, thanks!

I think the removal of npm_config_argv will also affect prebuild & friends, however. I'll check and then comment in #90.