That is a fair point. I don't think most people who use npms really pay much attention, though, and you're still just an npm update away from getting something unexpected (because really, who puts explicit versions in package.json?).
Deno does have lockfiles: https://deno.land/manual/linking_to_external_code/integrity_...
I prefer imports from URLs. And I loathe npm. I get why people would disagree though.
Re:Deno 1.0
by megavolcano on Wednesday May 13, 2020 @08:03PM
(#23173405)
Deno has lock files and caches files locally on first import.
Re:Deno 1.0
by eyelidlessness on Thursday May 14, 2020 @01:08PM
(#23182180)
I'm not sure how a lock file would help in this scenario, unless you're also committing your cache to source control (like a lot of folks did in the bad old days of NPM). The local cache is great, but that doesn't prevent the content of those URLs changing for someone who doesn't have access to your cache.
yeah, but we regularly clear out our cache and lock files, so this doesn't really solve the issue, unless you're commiting all of your packages
Re:Deno 1.0
by megavolcano on Wednesday May 13, 2020 @09:40PM
(#23174213)
Why are you _regularly_ clearing lock files? If you're bypassing lock files you're going to have the exact same issue with npm or yarn or any other package manager that downloads from the internet.
Dunno about OP but I pin versions in package.json because it allows me to control the versions and upgrade major versions only when explicit and necessary, and rely only on the lock file to keep it the same between commit time and the production build.
That doesn’t actually work and gives you a false sense of reproducibility and stability. Sure your top level dependencies might not change without explicit changes to package.json but every time you run npm install without a lock file all transitive dependencies are re-resolved and can change.
Always commit your lock files people
Re:Deno 1.0
by megavolcano on Thursday May 14, 2020 @09:38AM
(#23179320)
What about the dependencies of your dependencies? You're gonna get burned when a breaking change gets introduced a few levels deeper than your package.json. Not everyone follows semver perfectly, and sometimes malicious code gets distributed as one of these transitive dependencies.
That's fine for one developer pushing to production from their own machine. But I've you have aCI server and you're working with other people you're going to want to know that everyone is working with the same modules.
What! Clearing lock files seems wild. How do you know you're getting the right code when you install dependencies?
For Deno the only issue is the first time when you do not have it cached. Deno compiles in all dependencies when building so the only point of failure is the machine you’re building on.
I don’t know the state of the art anymore, but I’m sure they have ways to make it easy to vendor deps in the repo.
This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NPM world does not currently have.