251–260 of 478 posts
I feel the real issue here is downstream package consumers not practicing proper dependency pinning. You can blame the Node ecosystem, the maintainer of the package, etc. but there are well-known solutions to prevent this kind of situation.
So you would exchange security for stability, if you use package pinning then you will end up with fosilized packages in your product, which will have all maner of security issues that have alresdy been fixed.
I feel the real issue here is downstream package consumers not practicing proper dependency pinning. You can blame the Node ecosystem, the maintainer of the package, etc. but there are well-known solutions to prevent this kind of situation.
So you would exchange security for stability, if you use package pinning then you will end up with fosilized packages in your product, which will have all maner of security issues that have alresdy been fixed.
And the source code of the library is: function isPromise(obj) { return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; }
Earlier quoted context omitted.
Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.
That line of reasoning suggests progress isn't being made and we are just reliving the past.
Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is small enough, and easy enough to reason about, I'll just copy-pasta that motherfucker with a comment citing the source and date it was pasta'd (license permitting). Things like this are so not worth a package, ever, it's something when you see it you go "oh yeah,…
create-react-app contains over 1000 packages. How long would it take to review all of those?
Earlier quoted context omitted.
Yep. One of the very nice things about npm/node versus python or go or some others is that package locks and dependency pinning is possible. But few people seem to use it. I’ve seen reports of people using a go library that gets a minor update and breaks their app, at which point they become SOL as go always installs the lad test version. I myself have been working in python projects where the dockerfile simply says…
It's not true that Go always installs the latest version of a dependency. `go get github.com/x/y@v1.3.4` installs v1.3.4 of x/y, assuming there is a tag matching that.
The issue I’ve seen is:
https://github.com/go-yaml/yaml/issues/558
> Please do follow semver as it's a nightmare for us to manage particularly using go module (you can't stick to a particular version).
And of course everybody’s idea of a breaking change is different, so this idea that you can’t install a particular version seems unworkable.
Earlier quoted context omitted.
Wow just wow. So here's your new Promise object: class World { then () { return 0; } } isPromise(new World) // true If there really isn't a safe and better way to tell if an object is an instance of Promise…then color me impressed.
There are custom Promise implementations (for reasons), such as bluebird.js. If you're supporting legacy browsers, there will be no standard Promise object. So the simplest way to check for the Promise contract is the code posted. But yes, in an ideal world, one would be able to just do `promise instanceof Promise`.
For many who are hell-bent on entering these companies, yet have no known packages under their belt, they very well might fire off a one line package that actually gets some downloads, to be better "prepared" when screened.
Earlier quoted context omitted.
And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.
The "magical security updates" theory has never worked. Breaking insufficiently-pinned dependencies are vastly more common than unnoticed fixes on patch releases. On balance, semver has been good for javascript, but to the extent it contributed to the popularization of this dumb theory it has been bad. Production apps (and by a transitive relation, one supposes, library modules) should be zealously pinned to the fewe…