Checksums, solve a different problem. How does a developer know his code which works on his laptop will work on production. One of, but not the only, conditions for that are that his development artifact builds with the same dependencies as it will build in production. Their are a lot of possible causes for Dev/Prod to differ wildly. One of them are poor build practices.
I recently discovered that in node 10.10 (IIRC), you need oracledb < 4.0.0 whereas on other versions of node like node 10.16, you can use oracledb 4.0.1 (again, IIRC). I discovered this via the message when it blew up on application start, since it's not encoded in the package versions.
Weird that it didn't complain during building or installation.
Anyway I had one project where I couldn't use `async` `await`, because apparently this feature requires Babel 7, which in turn requires a version of node fresh enough to support generators.
This tends to happen, but it's rare to discover such an issue only after starting the application.
> Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.
I use to have this concern, but it's really not an issue with modern package managers. Even without a checksum in a lock file (e.g. gem bundler), I haven't actually had a deployment break because of dependencies changes. The biggest issue is being blocked for a couple hours because a package repo went down.
Most of this is solved by using a self-hosted or 3rd party proxy package manager.
There's loads of ways to know what you are using without needing to strip mtime's from zip files.