31–40 of 65 posts
This just saddens me deeply. Of all the ways this could have been done and all the package managers they could have used they picked npm. I bet some day we'll have a Linux distro with npm as the system package manager here on HN.
I need a medium account to read this for some reason.
> "This is your last free member-only story this month. Sign up for Medium and get an extra one" Well, that's about the end of medium I think.
Earlier quoted context omitted.
I guess my comment appears rude, which wasn't intended, I just find npm a troublesome piece of software that is passable as a package manager for the javascript ecosystem, but not a tool one solves problems with if there are viable alternatives.
When you have one thing to nail and already own a hammer, why go and buy another one? Even if it's not a good one, it's gonna do the job, and be the least trouble.
Earlier quoted context omitted.
Turn off Javascript. They don't (yet) have an SPA and it degrades appropriately for disabled users.
I'm not going to expend any effort to circumvent medium's nonsense. The content there isn't of consistently high enough quality to justify jumping through any hoops. Any barriers they put up will just result in me not consuming content hosted there.
Earlier quoted context omitted.
I haven't read the article yet, but I would assume they want versioning, history, checksumming and verification. All that stuff is worthwhile, it's just unfortunate npm is such a heavy dependency to achieve it.
Debian apt gives all these things and would be less of a heavy dependency.
The official docs are like a deep man page and do not have simple use cases, like, create a pkg for a binary
or create a pkg for a binary with systemd
or how to distribute a pkg of .so
IMO if the .deb and .rpm maintainers invested some time in modernizing their official pages with lots of quick starts and guides it would bring a lot of developers to their side.
(And in this specific case they needed more than Linux support)
Earlier quoted context omitted.
When you have one thing to nail and already own a hammer, why go and buy another one? Even if it's not a good one, it's gonna do the job, and be the least trouble.
The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.
Earlier quoted context omitted.
I haven't read the article yet, but I would assume they want versioning, history, checksumming and verification. All that stuff is worthwhile, it's just unfortunate npm is such a heavy dependency to achieve it.
Debian apt gives all these things and would be less of a heavy dependency.
Earlier quoted context omitted.
I haven't read the article yet, but I would assume they want versioning, history, checksumming and verification. All that stuff is worthwhile, it's just unfortunate npm is such a heavy dependency to achieve it.
Debian apt gives all these things and would be less of a heavy dependency.
I wish commentors would read the article. Why didn't they use the os package manager? Which OS? Their build clearly builds for osx, windows, and Linux.
1. clone cli repo 2. run goreleaser 3. copy binary to desired path
sure, it's not 1 step (can be condensed with a build script), but it does teach the other engineers how to roll their own cli tool and contribute back if they fix a bug in it.
Or if the blog indicated that not all engineers understand golang and build tools, and there's too many teams - that'd be good for blog context. Hopefully the author didn't spend much time in figuring out or being too clever in making this "hack".