801–810 of 1001 posts
Alright, time to start committing `node_modules` to my git repo. It'll have the added benefit of reproducible builds.
Earlier quoted context omitted.
> only updating if you know what the update contains People suck at this. What this actually tends to do is mean "no updates, ever" unless you have a particularly rigorous culture of dependency management.
Or we get a culture where upstream writes in more detail what an upstream is supposed to contain and downstream verifies that the update indeed does what they write. If this leads to fewer updates overall, I have no problem with that.
a culture where upstream writes in more detail what their code is supposed to do and downstream enforces that the software indeed does (not do anything beyond) what they specified
It didn't lead to fewer updates, it led to less usage of SELinux.
Earlier quoted context omitted.
They were using extreme numbers to say that even then you barely hit 10x. That's why the number they used for a living wage is so low too.
I just don’t think HN is interested in this anymore. There was a time. It’s gone now. Dumb comments saying software engineers make 100x a living wage (as if this would be a bad thing) are the flavor du jour. It’s hard not to respond in kind. But thank you, for what it’s worth. I remember you from 2010. It was quite a time.
Earlier quoted context omitted.
I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?
In browser land, the less code you ship, the better. Removing dead js code is hard, because of its dynamic nature and using common js imports making it harder for treeshaking algorithms. So, people had incentive to write and use smaller packages. Now, the situation has improved. If you use esmodules all the way, and only import what you need, then your bundler can remove unused modules from final build
That's kinda funny. These node tools I run into these days usually take forever to install, waste a lot of space due to creating their own package mirror and generally are prone to break because of dependencies.
There is usually nothing tiny about them, even thought they only have a few lines of code.
Earlier quoted context omitted.
> 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] That hasn’t been true for 7 years now, it was changed after the left-pad incident and that article everyone keeps quoting is from 2016. Deleting a GitHub repo or a package does not remove it from npm as part of their p…
They can still delete the package from NPM can't they?
Earlier quoted context omitted.
To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them
A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.
Earlier quoted context omitted.
How does that solve the issue here of new broken versions of packages being published?
That's another JS ecosystem widespread malpractice. Autobumping versions, or version ranges as they're called in Maven land. Dependencies should only use fixed versions and all updates should be manual. You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
You need to ask npm to upgrade or delete your lock file and node modules to run into this issue.
Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…
How many other maintainers are getting increasingly annoyed at the users of their code? Entitled users demanding changes to fit their use cases, megacorps using the code for free, other megacorps forking the code and launching it as a commercial service, we've been hearing for years about the problems of being an OSS maintainer. Focusing on the troubles of this one person is a mistake. Of course the more "unbalanced"…
I for one enjoy if anyone makes money with help of my code. I very well know I wouldn't have made it so far without many many others having chosen this way before.