111–120 of 155 posts
Earlier quoted context omitted.
Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.
There’s plenty of languages with vast standard libraries and which also have 3rd party libraries that offer the same feature as something in stdlib but more enhanced against a specific metric. You see it in Go, Python, .NET, etc.
Earlier quoted context omitted.
There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.
It’s not key comparison issue: const idx = [1,2] const m = new Map m.set(idx,"hi!") console.log(m.get(idx)) // outputs "hi!" console.log(m.get([1,2]) // outputs undefined That last line has created a new array object, and Map is made to be fast so checks equality by reference. Ah, which is what you to be able to change. I guess you would want to pass a new map a comparator function, so that it does a deep equal. That…
Stringification is a very crude hack, and it doesn't even work in all cases - e.g. not if a part of your key still needs to be compared by reference. Say, it's a tuple of two object references, describing the association between those two objects.
Either way, the point is that this is really basic stuff that has been around in mainstream PLs for literally many decades now (you could do this in Smalltalk in 1980!).
Earlier quoted context omitted.
This is why I prefer vendoring dependencies. I have to actually code review them.
I'd be called insane if I suggested it. I work with dotnet and I'd rather not add all the code in newtonsoft json and manually review each line. I mean where does it stop? Why not have everyone in the world code review asp.net and dot net libraries for every single website project at that rate?
You can import a list of audits from trusted auditors, which should cover all popular packages. Now you have to audit dependencies that aren’t well-known in the community, which really is the set of dependencies that you should take an extra look at. The big popular JSON libraries can be audited by either Microsoft or some of the other large projects that are using them.
You’d explicitly share your trust list in your audit file, and anything (updates or new packages) that isn’t trusted by you or one of your listed auditors is flagged for auditing.
Earlier quoted context omitted.
If NPM made some tweaks this might become trivial. Keep a node_modules/packagefiles with all the .zips that you commit to your source control. The expanded files can be kept out as they are now recoverable just using zip!
Wouldn’t the opposite be better? I’m not sure you could take advantage of the vast majority of files in the zip files being unchanged if you kept compressed archives.
Earlier quoted context omitted.
Honestly, how go does package management is pretty good.
It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy. Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some de…
That's what the Go module proxy is for. The authors can move or remove their repositories as much as they want, I as a dependent am not bothered by it. They would have to go through an official vetted process to get it removed from the proxy.
I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?
Is npm specifically vulnerable to this kind of thing? Or is it just a cultural elelemnt of npm that there are more micro-packages?
Has no one thought of that? It seems like it should have been obvious that such an absolute rule could be easily abused to troll the system at scale.
Not sure if it's a problem though, perhaps all unpublishing requests should be reviewed by someone at the registry (and granted only when it makes sense).
What a dissatisfying non-apology of an apology. > First, just want to apologize about any difficulties this package has caused. No rationale. No shame. Just the word “apologize” in a sentence. Who downloaded it though? Surely as a dev if you download such a package it’s on you?
Why does he even need to apologize? If anything, npm should apologize and thank him for revealing a huge issue in their unpublishing policies unmaliciously.
Earlier quoted context omitted.
I’ve started thinking package management has too much trust now. Ideally, but probably unpractically, projects should check in their packages like they used to under /lib or /third_party, and be much more suspicious of new package dependencies. Basically, you would need to start accepting that you are responsible for any dependencies you choose to include. Any upstream changes you would need to evaluate and bring in…
If NPM made some tweaks this might become trivial. Keep a node_modules/packagefiles with all the .zips that you commit to your source control. The expanded files can be kept out as they are now recoverable just using zip!
What problem does this solve?