131–140 of 478 posts
is it idiomatic in the JS world to always express dependencies in the "version X.Y or higher", vs "version X.Y"? Most of my experience is from the java/maven world where you're playing with fire if you don't just make it "X.Y".
Earlier quoted context omitted.
>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.
Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.
Another good way to not have to depend on big/tiny/weird modules published by others is to use coffeescript. So much finicky logic and array-handling just goes away.
Earlier quoted context omitted.
Know what happens every time people like you say this here on HN? They post the one-liner they would have manually implemented in their code base and it's wrong . The one that comes to mind is the "is-negative-number" package. Yes, the geniuses of Hacker News, after finding out there was an npm package for determining whether something was a negative number, could not correctly implement that function. You and everyo…
Maybe its a failure of the language when it takes a third party package to determine if a number is greater than or less than zero?
Earlier quoted context omitted.
Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.
Not everyone would use it, that's my point. The inertia behind the existing system is too great, especially in enterprise. All that would happen is that library would become just another Node package, and then you've got the "n+1 standards" problem. The "nonexistent standard library" wasn't a problem in the days when javascript development meant getting JQuery and some plugins, or some similar library. It only became…
If the right people would provide the library, it would be used by enough people.
> Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser
Whats the point of inside or outside of the browser?
The problems that beset the Javascript ecosystem today are the same problems that beset the Unix ecosystem, back in the 90s when there still was one of those. TC39 plays the role now that OSF did then, standardizing good ideas and seeing them rolled out. That's why Promise is core now. But that process takes a long time and solutions from the "rough consensus and running code" period stick around, which is why instan…
This analogy doesn't hold up at all. The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever. But there was also the possibility, for non-software businesses, to pick a platform and stick to it…
I agree that VC money is ultimately poison to the ecosystem and the industry, but that's a larger problem, and I could even argue that it's one which wouldn't affect JS at all if JS weren't fundamentally a good tool.
(To your edit: granted, and React, maybe and imo ideally plus Typescript, looks best situated to be on top when the whole thing shakes out, which I agree may be very soon. The framework-a-week style of a lot of JS devs does indeed seem hard to sustain outside an environment with ample free money floating around to waste, and React is both easy for an experienced dev to start with and supported by a strong ecosystem. Yes, led by Facebook, which I hate, but if we're going to end up with one de facto standard for the next ten years or so, TS/React looks less worse than all the other players at hand right now.)
Earlier quoted context omitted.
Install any moderately complex nodejs lib or app and it will throw tons of warnings, ignored errors, and security issue alerts. As you should with any app running in production, lock down everything and watch network traffic because there are innumerable backdoors in the JavaScript ecosystem.
My company's current production electron app has 360 npm dependencies. We have CI for the UI but not for the USB/FFI stack, so any time we have to touch that code everyone blanches. > innumerable backdoors in the JavaScript ecosystem. Same goes for Python and CPAN. Any "click here for fancy module" installer has this problem.
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.
I mean, if you have to assume deliberately adversarial action on the part of your own codebase, you may have worse problems than having to duck-type promises.
https://doc.rust-lang.org/std/primitive.bool.html#method.the...
https://doc.rust-lang.org/std/cmp/enum.Ordering.html#method....
Everyone crying about this on the Internet would do better to just take it as an easy lesson: pin your dependency versions for projects running in production. This was an honest oversight, and even somewhat inevitable with so many expected supported ways to import/export between cjs mjs amd umd etc. It will happen again. And when it happens the next time, if it ruins your life again, take issue with yourself for not…
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.
Pinning isn't meant to be a forever type of commitment. You're just saying, "all works as expected with this particular permutation of library code underneath." And the moment your dependencies release their hot-new you can retest and repin. Otherwise you're flying blind and this type of issue will arise without fail.
Earlier quoted context omitted.
I'm sorry if you were unaware, but they absolutely do that, and were doing that long before go was.
I am aware of package lockfiles. If deps are immutable, then nothing anyone does in any other package (short of having the package repository take the code down) should be able to break your future builds. If that were true, TFA would not be news.
They are. You're only affected if you don't use a package-lock.json or start a new project (which will pull the latest versions of the dependencies).
Earlier quoted context omitted.
By doing that they would avoid this issue, for sure. They would also introduce security issues by using old versions. And this would do nothing for the fact that `npm install eslint && ./node_modules/.bin/eslint` was also failing.
It's not like pinning means you can /never/ update. You just get to do it on your own schedule. You can even automate updating to some degree -- running your tests against the latest everything and then locking in to those versions of all goes well.