Can people please stop using 'lockfile' for things that aren't lockfiles?
Particularly if you're storing important data using the name of a file type that, for the last few decades, has been something any Linux or Unix user can delete without significant consequence.
I have the same problem with "tree shaking". Granted it's not a bastardization of an established term, but it's a reinvention and confounding of terms we already had.
I guess the one thing to take away from this is that js tool authors and c tool authors don't talk to each other enough.
As a curiosity, and I say this as someone who has a significant C background, what would you call a similar concept in C? I know that it happens (having been burned by missing symbol errors due to incorrect link ordering), but I don't actually know what it's called.
Typically it would be called dead-code elimination. The creator of rollup who popularized the term tree-shaking disagrees that they are the same, but his argument is not super compelling (not that it really matters either way).
Unfortunately, despite years of bug reports, neither NPM nor the new kid on the block are deterministic when invoked on multiple builds on the same machine simultaneously. It's almost like their developers never use continuous integration environments. Ironically, if they used an actual lockfile in the traditional sense of the word and did that properly...
1. The amount of noise in the lock file likely does matter for teams of any modest size
2. Yarn doesn't guarantee determinism for hoisting between different versions, but... in reality there's no reason to expect different behavior simply because there's a version difference.
The second point is pretty key, because it means yarn can deal with the issue through fairly standard means (like versioning, documentation, warnings, etc). Plus, most orgs already handle versioning and compatibility between tools in some form or other.
Finally, NPM 5 doesn't actually guarantee hoisting is deterministic between versions, they just have enough information that they COULD guarantee it. For all we know, NPM 6 will change the format of the file entirely... or perform new hoisting optimizations based on the lockfile that are incompatible with the logic in 5.
It's just about moving a dependency up a level of node_modules if they are compatible. So if for example 2 packages A and B have the same dependency on babel-core, instead of node_modules/A/node_modules/babel-core and node_modules/B/node_modules/babel-core you could just have node_modules/babel-core.
Particularly if you're storing important data using the name of a file type that, for the last few decades, has been something any Linux or Unix user can delete without significant consequence.