meanwhile I can regularly override even major release versions of dependencies in elixir with out breaking changes. dependency fickleness has always been a huge issue for me when working with node.
A one-line package broke `npm create-react-app`
451–460 of 478 posts
Re: A one-line package broke `npm create-react-app`
#452Earlier quoted context omitted.
Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise fal…
No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing w…
For foreign-origin iframes, that's exactly what people do using `postMessage`. But for same-origin iframes there's no need since you can access the iframe's context directly. So people can (and do) write code exactly like this that accesses data directly.
And it was given a Promise. You just shouldn't use instanceof in multi-window contexts in JavaScript. This is why built-ins like `Array.isArray` exist and should be used instead of `arr instanceof Array`. Maybe you'd prefer to write to TC39 and tell them that `Array.isArray` is wrong and should return false for arrays from other contexts?
There's no use jumping through hoops to avoid admitting that OP made an error. They were wrong and didn't think of this.
Re: A one-line package broke `npm create-react-app`
#453I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…
I honestly have no idea if you prefer Node.js or J2EE after reading this comment.
They mean that they would only trade Node.js for J2EE the day they can also quit (so that they don't have to use J2EE).
Re: A one-line package broke `npm create-react-app`
#454Earlier quoted context omitted.
In one of Robert "Uncle Bob" Martin presentation you may find the answer. The number of developers duplicates each 5 years. That means that any point in time half of the developers have less than 5 years of experience. Add to that realization the fact that inexperienced developers are learning from other inexperienced developers and you get the answer on why we repeat the same mistakes again and again. I guess that i…
> The number of developers duplicates each 5 years You probably mean "double" here, but the bottom line is that there is zero data to back up that claim. He literally made up that number out of thin air to make his talk look more important.
Let's say it's 10 years, or make it 15 years, for the sake of the argument.
How does that change his original argument?
Re: A one-line package broke `npm create-react-app`
#455Earlier 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.
This is a promise as far the language is concerned (and `is-promise` package uses the same definition as the language) - it's sufficient for an value to be an object and to have a `then` property that is callable. For instance, in the following example, the `then` method is being called. (async () => ({ then() { console.log("Called") } }))()
[deleted]
Re: A one-line package broke `npm create-react-app`
#456Earlier quoted context omitted.
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 get notifications to update my Rails apps from GitHub as a matter of course when there's a CVE in my dependencies. Does this kind of thing not exist/is impractical for JS?
From my experience of getting ~30 of those notifications per week for a handful of JS repos, I can very much assure you that it does exist.
Re: A one-line package broke `npm create-react-app`
#457Earlier 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.
Or just: const p = {then: () => 0}
Well, an object with a then() method is a promise.
Promise.resolve({then: () => console.log('called')})
Promises autoflatten since you can't have Promise>, so you'll see that this code prints 'called'.
Re: A one-line package broke `npm create-react-app`
#458Earlier quoted context omitted.
No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing w…
GP's comment screams XY problem which seem to be increasingly common these days.
If you think pointing out a bug due to an edge case someone didn't think of is the XY problem, I'm afraid you don't know what the XY problem is.
Re: A one-line package broke `npm create-react-app`
#459I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those functions into their own project or there should be more common used packages that bundle these one-liners. I mean is_promise() and left_pad() are not worth their own package. Packages-dependencies of 10000 packages for trivial programs are just insane. Is someone…
>Is someone going to fix that? Probably not. There is too much code in the wild, and NPM owns the entire JS ecosystem, and there has been too much investment in that ecosystem and its culture at this point for a change in course to be feasible. The JS universe is stuck with this for the foreseeable future.
It's just a cultural problem. There's no reason why a library should abstract away `typeof obj.then === 'function'` if they want to check if something is a promise. Just write a one-liner the same way you don't pull in a `is-greater-than-zero` lib to check x>0.
The problem is when you try to level criticism at this culture and a cloud chorus of people will show up to assert that somehow tiny deps are good despite these glaring issues (a big one just being security vulns). And funnily enough, the usual suspects are precisely people publishing these one-liner libs. Then people regurgitate these thoughts and the cargo cult continues.
So there's no "fix" for NPM (not even sure what that would mean). I mean, anyone can publish anything. People just have to decide to stop using one-liner libs just because they exist.
Re: A one-line package broke `npm create-react-app`
#460Earlier quoted context omitted.
It should be fairly simple to look up people describing themselves as developers in the census data I think?
Does the census actually track that? I just did the questionnaire last night online and it didn't ask me anything about my occupation. Or did you mean something other than the US Census (e.g. GitHub or Stack Overflow or LinkedIn profiles)?
The long form asks about your line of work. Most people get the short form.