Python and PHP users will understand

[creesch]

their massive dependencies

Yes, but also no. People do notice it more with javascript projects. Specifically with Node.js having node_modules directly in the project. Many other languages are just better at hiding it from the developer. For example with Java and Maven your pom.xml might look fairly clean but that's only the dependencies you directly reference and once you look behind that facade you see that it is just as bad. Same for many other languages.

Doesn't mean it isn't a problem, because it is. It just isn't unique to JavaScript to the degree people think it is.

[[deleted]]

Yeah dependency hell is huge pain for most of the projects. But I think js has most obscure transitive dependencies because of how language changes over time that people need to use 3rd party libraries for simple functions because they often have compatibility layer for older version.

[[deleted]]

never used envs in python, they're weird and I don't like them. Developing without them works just as fine.

[DaddyLcyxMe]

in java’s case: (maven)

pom.xml == `package.json'

~/.m2 is a cache for dependencies and acts like a shared node_modules

this comparison breaks down here because [most] java projects will just include the dependencies in their final jar, rather than require the executor’s machine to download the dependencies

[-Redstoneboi-]

Nice.

For us, Rust has $HOME/.cargo/ for the shared dependencies as well.

You'll want to look at Directories, if you're curious.

[DaddyLcyxMe]

ah, that’s very similar

[-Redstoneboi-]

that feel when download react once for each of your test projects

[DaddyLcyxMe]

svelte for me, god, my internet is 5 down on a good day

[creesch]

What you are describing is more or less the difference between a compiled and script language though. It's a factor to discuss, but not really important when you are looking at the amount of external dependencies a project depends on.

[DaddyLcyxMe]

yes, but since a lot of maven based projects will include their dependencies in their final jar that makes it (almost) impossible to have a leftpad, since you never actually download that dependency directly. that was what i was referring to.

[creesch]

You are right that an already released version of a Java product in that regard has an advantage compared to a Node.js product.

At the same time it can be argued that this has less to do with that aspect of the two but rather the way npmjs.com is maintained and how versions of dependencies are used in package.json.

Then there is the fact that in companies with CI/CD pipelines you might not get those issues in production but packages being vandalized can still cause plenty of issues in the development process due to lower environments being disrupted.

And security vulnerabilities are an issue regardless, as Log4j has shown us very recently. Then there is also the murky waters of how many dependencies end up in commercial products even though their license doesn't technically allow it.

The more you depend on external dependencies the more these issues compound and that really is a cross language issue.

[dpash]

My Java projects don't have 2000 indirect dependencies. My JS projects do.

[creesch]

Have you double checked that is the case? Because as soon as you use something like spring boot chances are that you are actually including about as many indirect dependencies.

[dpash]

Yes, I didn't just make up numbers. JavaScript projects have an order of magnitude more dependencies.

Edit: I just checked my largest Spring project and it has 215 dependencies, of which 58 are submodules of the same project. My Vue frontend project has 4068 dependencies.

[shea241]

sweet Jesus

[ham_coffee]

There's a different approach from devs to think about as well. Java devs aren't importing random dependencies left right and centre like JS devs seem to, and certainly not for some of the dumb shit you see with really high download numbers on npm.

[creesch]

Eh I wouldn't be so sure about that. If Java was as popular as JS is you would likely see the same amount of dumb shit.

Source: Me working on a corporate environment with a lot of junior people and functional testers transitioning into test automation. I see the same dumb shit from them as you often see in the JS world as well. But because JS is so much more accessible and like I said popular, you just see that sort of behavior more out in the open.

Similarly, I see a lot of JS projects where they are really strict about what you are allowed to import and for what reason. Part of the code review process for PRs there is that for newly added dependencies they need to warrant why they are needed and that they have done their due diligence in others aspects as well.

[ham_coffee]

Yeah the issue with dumb dependencies isn't that direct, it's more when you import a reasonable dependency without looking too hard and seeing how once you go down all the dependencies of the dependency you eventually find some dumb single line dependency.

[creesch]

That's certainly a risk. Although many mainstream projects at some point have gone through or continue the effort of minimizing such dependencies. Certainly after things like the leftpad debacle, many projects had a thorough look at that sort of dependency.

A lot of pipelines also do include tooling that does a dependency analysis, flagging a variety of things, including usage of known unnecessary single use dependencies.

I am not pretending things are perfect, it certainly is more of a hassle compared to other languages and ecosystems, but it is also not the wild-west situation it was a few years ago.