Ride down into JavaScript dependency hell • Hacker News Board

Re: Ride down into JavaScript dependency hell

#131

Post by filleduchaos » Sat, Apr 11, 2020, 10:34 PM UTC

mschuetz wrote: post #56

matheusmoreira wrote: post #48

Earlier quoted context omitted.

Why are small packages bad? Independent functions should be versioned and distributed independently. Otherwise we get several utility packages which are nothing but collections of independent functions. Widely used packages should form the basis of a standard library that is distributed with the language itself.

Every separate package adds overhead and another maintainer that you've got to put your trust in. I'd rather have few packages of well trusted maintainers instead of a thousand packages from god knows who. Personally, I've made it a habit to not add anything that requires trivial one liner garbage packages, which amounts to not installing any dependency that uses anything from Jon Schlinkert (so no Webpack). Unfortun…

Have you considered using Rollup? I've personally found it delightful.

Re: Ride down into JavaScript dependency hell

#132

Post by lioeters » Sat, Apr 11, 2020, 10:53 PM UTC

erik_seaberg wrote: post #130

lioeters wrote: post #128

Earlier quoted context omitted.

That's not always true. Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever). Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first. R…

I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.

> explicitly depending on our fork of their library would be clearer and safer.

I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.

Re: Ride down into JavaScript dependency hell

#133

Post by Dylan16807 » Sun, Apr 12, 2020, 12:22 AM UTC

matheusmoreira wrote: post #74

oefrha wrote: post #73

Earlier quoted context omitted.

Point to me one package in Debian that depends on thousands more. Oh and I was a maintainer for a major package manager back in the day for crying out loud (was responsible for overseeing the general health of the project as well as directly responsible for maybe a couple dozen individual packages). Never seen this kind of madness.

I don't know about Debian but Arch Linux has huge package groups and metapackages. https://www.archlinux.org/groups/x86_64/kde-applications/ https://www.archlinux.org/groups/x86_64/pro-audio/ The Arch Wiki recommends the use of these huge packages. I don't see any reason why it wouldn't scale to a thousand packages or more.

Groups are very different from dependencies. And a big meta-package is there for user convenience to get a bunch of stuff. It's almost never going to be depended on; if something needs a package or two from the group it will depend on that directly.

Re: Ride down into JavaScript dependency hell

#134

Post by jacobolus » Sun, Apr 12, 2020, 12:43 AM UTC

rootlocus wrote: post #125

jacobolus wrote: post #123

Earlier quoted context omitted.

> For example: The npm package "is-even" depends on the "is-odd" package. (In case it's not clear, this is a real package, not a made-up example.) In most other languages, these would be bundled together into an Integer Utilties package, if they're not already part of the standard library. In NPM, they are separate packages. People should not be using these functions at all, in any language, in a standard library or…

If the standard library includes a variant for these or any other functions, it's probably idiomatic to use them. They handle edge cases, are better optimized and they're explicit.

There is no way that any Javascript library function is "more optimized" than just using `n % 2`, which is also plenty descriptive.

If this is very performance sensitive you can try using the somewhat more obscure (because many people have minimal experience with bitwise operators) `n & 1` instead.

Given an integer input, thare are no "edge cases" to worry about here. If you expect floating point inputs, you need to think carefully about what the correct output should be anyway. A library isn’t going to save you.

(If your "edge case" is that someone might want to know whether a string is even or odd... well, you have other problems.)

Re: Ride down into JavaScript dependency hell

#135

Post by toyg » Sun, Apr 12, 2020, 12:43 AM UTC

hn_throwaway_99 wrote: post #38

dep_b wrote: post #36

Earlier quoted context omitted.

iOS dependencies in Cocoapods are including less than 1 other packages on average (1). The most I see are Alamofire (a networking package people keep using for reasons that I do not fully understand) and Starscream (a Websocket implementation, that's pretty hard to write from scratch to be honest). Having unnecessary dependencies is pretty much frowned upon. One of the reasons is that the iOS SDK is really complete b…

Java didn't have a decent date implementation until Java 8. > If somebody could just come up with a standard library for JavaScript that is really widely adopted I think the amount of packages can be cut back dramatically. As this article points out, I think that lodash is that for many people.

Java has had exact datetime implementations since what, 1.3? 1.2? Sometime in the ‘90s anyway. They weren’t fun to use but they worked fine, had the concept of multiple calendars etc...

JS’s version of Date in comparison has always been a toy.

Re: Ride down into JavaScript dependency hell

#136

Post by parhamn » Sun, Apr 12, 2020, 12:44 AM UTC

jessaustin wrote: post #80

parhamn wrote: post #47

Earlier quoted context omitted.

Sure (upvote) and we dealt with it accordingly after some confused digging. On a more general level I’ve never seen something like that in a package manager. It seems as though some of the language features (like the singleton I mentioned) would make it obvious that arbitrarily duplicating packages and scoping them to sub packages is a major no-no, as in most languages I’ve dealt with.

It seems like a weird thing about React, or maybe how you're using it, that this is a problem. Most packages, and the language itself, handle multiple simultaneous versions of dependencies without issue. If packages are doing the old-fashioned "stick a property on window" thing instead of just getting required or imported browserify-style, they can step on each others' toes (and it's totally possible that React is du…

That’s not really relevant, right? No mater the loading/transpiration step, you lose a lot of language guarantees when you can load multiple of the same packages, including:

- function/object identity checking I.e “package.func !== package.func” in many cases places.

- module level singletons and registry (e.g createContext useContext)

- single initialization

- others I can’t think of

That’s not typical and I was surprised by it.

Re: Ride down into JavaScript dependency hell

#137

Post by halostatue » Sun, Apr 12, 2020, 1:22 AM UTC

stickfigure wrote: post #95

ng12 wrote: post #83

Earlier quoted context omitted.

They also strategically avoid mentioning the payoff which is that your project is entirely self-contained. `node_modules` is at once your complete development kit, build tool, compiler, and collection of runtime dependencies. Once you check out a node project with a package.json you can reasonably assume you can install it and run it anywhere. A docker image for a node project should just be "install node && npm buil…

I'm totally baffled by this statement. Find me a mainstream language that's more complicated than this? "Checkout and build" works pretty much everywhere? I mean, you need the right version of mvn or pip or whatnot... just like you need the right version of npm. If anything, node/npm deserves special mention for NOT having reliable repeatable builds. Part of this is that a lot of packages rely on native code. But mos…

Worse than that: lock files aren’t lock files the way that they are in every other language package manager that has lock files. In Cargo, Bundler, and Mix, you specify a pessimistic version (~> 2.1) and you may get 2.1.1 or 2.3.0. But that version is _always_ the same for every developer because the lock file locks the version and you explicitly upgrade after that.

I recently had a case where a developer joined us on a project and he got a different version of a package than I did because the lockfile didn’t constraint the dependencies and sub-dependencies and everything else. (For that you have to pass an explicit parameter like `--ci` or `--frozen-lockfile` depending on which of three different package managers you use.)

Bollocks, I say.

Re: Ride down into JavaScript dependency hell

#138

Post by halostatue » Sun, Apr 12, 2020, 1:37 AM UTC

williamdclt wrote: post #58

brobdingnagians wrote: post #33

Earlier quoted context omitted.

These types of issues are the biggest reason why I avoid javascript/npm projects. I came back to a project after a few months and it was broken, had to rewrite some parts and upgrade other parts just to get it to run again.

I'm sorry but for all the flaws of the NPM ecosystem, version locking is not one (both `npm` and `yarn` do much much better than anything in Python). There's no reason a correctly set-up project would magically break with time. I don't love NPM anymore than the next guy, but my blame will go to the dev in this case.

No, version locking is a disaster in npm and yarn both (and ppm appears to do the same thing). For it to be _safe_, you have to opt into `--ci` or `--frozen-lockfile`.

Cargo, Mix, and Ruby’s Bundler _all_ do an infinitely better job because they don’t let dependencies upgrade on you behind the scene. Their lockfiles are really lockfiles. No ifs, ands, or buts.

`--frozen-lockfile` and the equivalent should be the DEFAULT behaviour, not this pseudo-locked nonsense that currently exists.

Re: Ride down into JavaScript dependency hell

#139

Post by halostatue » Sun, Apr 12, 2020, 1:40 AM UTC

williamdclt wrote: post #54

tluyben2 wrote: post #42

I cannot understand how people work with this. I work with many different technologies and try to avoid JS, but some times I have to. The past weeks I have worked on a React Native project that was written by someone else; what a horror show. I mean it wasn't the worst code by the previous guy but even in a few months a lot is simply broken and not 'best practice' anymore. Compared to most other environments I work w…

I don't agree with you on this. The JS (or NPM) way makes it a pain to audit a project due to thousands of dependencies, but it's far easier to "have everything working". `npm i && npm start` is as good as it gets in terms of "getting started" friction (with version locking): python is worse, ruby is worse, PHP is worse, Java is worse. React-Native has more moving pieces indeed, but it's not really JS's (or NPM's) fa…

If only version locking weren’t fundamentally broken in JS package managers. I’ve said it a couple of other times on this, but `--frozen-lockfile` should be the default behaviour. Under no circumstances should any developer get a different package version than what is locked in the lockfile. This is the exact opposite of what npm, yarn, and pnpm do with their lockfiles (unless you use `--frozen-lockfile` or `--ci`).

Re: Ride down into JavaScript dependency hell

#140

Post by d_watt » Sun, Apr 12, 2020, 2:15 AM UTC

jacobolus wrote: post #134

rootlocus wrote: post #125

Earlier quoted context omitted.

If the standard library includes a variant for these or any other functions, it's probably idiomatic to use them. They handle edge cases, are better optimized and they're explicit.

There is no way that any Javascript library function is "more optimized" than just using `n % 2`, which is also plenty descriptive. If this is very performance sensitive you can try using the somewhat more obscure (because many people have minimal experience with bitwise operators) `n & 1` instead. Given an integer input, thare are no "edge cases" to worry about here. If you expect floating point inputs, you need to…

It's funny, because in the case we're talking about, there appears to be edge case behavior if the number is a "safeInteger." While I agree in principle I would never import something as granular as "is-odd," just researching this specific package revealed an edge case someone ran into and solved, and you don't have to worry about as a dev if you take it off the shelf. https://github.com/jonschlinkert/is-odd/blob/master/index.js...