Rockslide

Just Dance Vance's shitposting doesn't even qualify as "ideas".

Figuring out what is true for npm v5 is quite the waste of time, given that we are currently at v11. And that's what this ancient stackoverflow thread is about. npm certainly has a troubled past, otherwise we wouldn't have yarn and pnpm and whatnot. But _today_, npm install works very reasonably with lockfiles.

npm install does install the exact versions from the lockfile. Even though this misconception gets repeated in every single thread about npm here on hn. npm install will not randomly update your direct dependencies, let alone transitive dependencies.

That first recommendation of pinning exact versions of each and every dependency is borderline insane. That's exactly what lockfiles are for. Which are used by default.

Well there are other lockfile updates as well, which aren't dependency version changes either. e.g. if the lockfile was created with an older npm version, running npm install with a newer npm version might upgrade it to a newer lockfile format and thus result in huge diffs. But that wouldn't change anything about the versions used for your dependencies.

> You've partially answered your own question here.

Is that the case? If it were ever true (outside of outright bugs in npm), it must have been many many years and major npm releases ago. So that doesn't justify brigading outdated information.

Yes. As someone who's using npm install daily, and given the update cadence of npm packages, I would end up with dirty lock files very frequently if the parent statement were true. It just doesn't happen.

How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.

Those stackoverflow posts are ancient and many major npm releases old, so in other words: irrelevant. That blog post is somewhat up to date but also very vague about the circumstances which would update the lockfile. Which certainly isn't that npm install updates dependencies to newer versions within the semver range, because it absolutely does not.

Well but the docs you cited don't match what you stated. You can delete node_modules and reinstall, it will never update the package-lock.json, you will always end up with the exact same versions as before. The package-lock updating happens when you change version numbers in the package.json file, but that is very much expected! So no, running npm install will not pull in new versions randomly.

> What's next We're improving the developer experience in three distinct phases: Framework -> Design -> Cloud

So the "cloud" part is where the enshittification will begin. Been there, done that, switched away from next.js :|

You have that mixed up, storage and ingestion is cheap in BigQuery but processing is exactly were they grab $$$

Yes the whole consultancy situation really is the icing on the cake - as the customer you pay for (alleged) experts in the field and get this as the result...

Sorry but that's nonsense. Partitioning is THE central cost controlling mechanism in BigQuery and the docs clearly state this. And it's an easy to use feature, so I'm not sure what makes you think using that would be as challenging as building your own query engine.

I don't have a lot of sympathy for people using their tools wrong. Using partitioning surely would have prevented this.