undefined | Better HN

0 pointsendymi0n8y ago0 comments

All of this feels like a classic case of "the perfect is the enemy of the good". Package and dependency management in Go is honestly a total mess today and with vgo challenging all current assumptions about how to generally approach packagement, it brings complete paralysis to the simple question of "how should I organize my dependencies right now".

As much as I loathe JavaScript or Ruby these days for their language, using npm or bundler simply feels sane despite all of their warts. Yes, `left-pad`. Yes, they do have their issues. But seriously, they just work and all open source packages comply to their specifications. And they can and do evolve gradually, like yarn shows.

It's just so funny how careful the Go community seems to tread about not breaking their language with all these Go 2 proposals and general resistance to new features — and then completely ignore this spirit to "move fast and break things" when it comes to package management.

0 pointsendymi0n8y ago0 comments

0 comments

5 comments · 1 top-level

pknopf8y ago· 4 in thread

> using npm or bundler simply feels sane

I feel the opposite. Lock files are awesome when your developing a package, but after you release it, you are at the mercy of all your dependencies in making sure that they don't break semvar. Each "npm install" will ignore any lock file your package was using during development.

It would be awesome if I could distribute a package-json.lock file with my npm package and have yarn/npm use it when resolving packages on fresh installations.

Yeah, this would mean that there may be duplicated libraries in your node_modules tree, each with a slightly different version, even if semver compat. However, people break semver to often anyway.

I want to deploy a package to npm and be sure that it will never break, ever.

regularfry8y ago

Can't you do this right now by specifying exact dependency versions in package.json? Lock files should be for applications, not libraries.

pknopf8y ago

Yes, but "npm install" will by default add a semver-compat package version. The vast majority of packages out there use what "npm install" gives you be default.

Furthermore, even if I use exact versions in my package.json, that doesn't stop my referenced packages from internally referencing semver-compat versions.

At the very least, you should reference exact versions at the top level. It is better than nothing.

irishsultan8y ago

> Each "npm install" will ignore any lock file your package was using during development.

That's true for npm, but not for bundler (luckily).

Groxx8y ago

This is essentially what shrinkwrap does. Apparently it has issues, but it's designed to be the lock file for your package.json.

j / k navigate · click thread line to collapse