511–520 of 1001 posts
AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint? I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such. What am I not see…
Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…
It's the same with packages, it's FINE to have to redo a bit thousand separator logic, do you truly need a transitive dependency hell with ^1.1.1 in the package list that auto upgrade at random !!? I've had several cases where the whole company is all hands on deck because some dep somewhere moved up and all subsequent builds fail - what are people doing in node, we never had these issues in Java.
Earlier quoted context omitted.
Does updating it with junk take any longer?
Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev mac…
AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint? I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such. What am I not see…
That's fine, but then the downstream shouldn't complain either when the code breaks, whether intentionally or unintentionally. The contract on paper disclaims all liability after all. There is a social contract and then there is the literal contract. A lot of commenters here seem to be willfully obtuse or simply ignoring the former.
Earlier quoted context omitted.
Time and time again I'll keep saying this: This problem is only solved with package repositories that require review by a maintainer to publish. Linux distributions solved this ages ago.
This raises an interesting business idea. How much would developers and companies be willing to pay for an npm alternative with human reviewers?
This might be controversial, but I feel like the default position should be that every package over a certain number of monthly downloads should be considered as being added to the standard library (along with paying maintainers a stipend and helping integrate into a release process).
I think we can have our cake and eat it too on this topic
Maintainer of Chalk[0][1] here, a very popular alternative to colors. Happy to help anyone that would like to port away from colors to chalk, or who might just have general questions about terminal colors. Just reply here and I'll see them. [0] https://GitHub.com/chalk/chalk [1] https://npmjs.org/package/chalk
Thank you so much for what you do.
Earlier quoted context omitted.
> if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner. The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is ju…
Permissions inside a programs own code seems incredibly difficult without radical change.
It's time for someone to make a Redhat, but for "safe" open source software libraries. My big enterprise would sign up for it in a heartbeat. We'd pay for access from an alternative NPM registry where everything is at least semi-vetted - someone at least looks at diffs before new versions get updated and made available. Sure, the "safe" repo wouldn't have as nearly as many packages as the main NPM repo, but if it had…
Use a language where you don't need to pull in 100 dependencies to create a useful application/service.
I do think there is space for someone to ship an "unofficial meta-package" for languages like JS to wrap all this stuff (I tried to do an analysis of npm once to figure out what would make sense but got lost in the weeds....)
Python (for me one of the gold standards on this front) has been hyping for a future with a much smaller standard lib and it makes me sad.
Earlier quoted context omitted.
> Regardless, it’s ridiculous to give something away openly under a permissive license and then later get angry when people use it exactly as you license it. Doing your best to live in a bad system does not invalidate the complaints you have about that system.
By publishing free, open source software he wasn't "doing his best to live in the system". That would involve exchanging his labor for currency.
That's the goal. Or at least one goal. But you can't just press a button and do that.
Being in charge of and an expert on open source software can be a way get people to buy your labor, but it's much harder than it should be. Instead many companies will demand you work for free, because it's open source!
Also trying to do something good for the world shouldn't make it so hard to make money. The companies get value but don't want to pay even a pittance.