Steps to reproduce:
- Start a Node project that uses at least five direct dependencies.
- Leave it alone for three months.
- Come back and try to install it.
Something in the dependency tree will yell at you that it is deprecated or discontinued. That thing will not be one of your direct dependencies.
NPM will tell you that you have at least one security vulnerability. At least one of the vulnerabilities will be impossible to trigger in your particular application. At least one of the vulnerabilities will not be able to be fixed by updating the versions of your dependencies.
(I am sure I exaggerate, but not by much!)
Why is it like this? How many hours per week does this running-to-stay-in-place cost the average Node project? How many hours per week of developer time is the minimum viable Node project actually supposed to have available?
You must log in or register to comment.
Because 99% of Node projects are web related, and if something’s vulnerable on the web it won’t take long to be abused
Also a great disadvantage with JavaScript being the official scripting language of the web so it needs to work in every browser, but not every browser will implement it the same way. Syntax between the browser and servers also gets conflated.
I’ve done frontend development in Java and it sucks major ass. The “advantage” of using one language for the whole project really ended up as a net negative. For any server-side project I’m totally fine using Java because for all it’s verbosity it’s secure, performant, and examples from 10 years ago aren’t useless.
Fron-end development with Java? You mean Java applets or something?
JSF for example. e.g. Primefaces https://www.primefaces.org/ I think there is something like Omnifaces too
Google Web Toolkit was a thing at some point in time. ;y current company still maintains some apps which are written in it.
Behold the horror of Vaadin: https://vaadin.com/docs/latest/guide/quick-start#add-code
Honestly looks like any other UI library/Framework for C#/Java.
However usually these elements are not instantiated/configured directly but from xml, yaml or json files that are built using some sort of GUI/Editor.
JSP used to be the shit back in the day. Imagine server-side rendered html through Java. Nowadays it’s properly regarded as shit, fortunately.
I tought JSP was just one templating solution like mustache, jinja2, Thymeleaf etc. But guess theres more to it.
My take: It’s because the “trust everything from everybody” model is fundamentally broken.
Note that trust is not only about avoiding malicious or vulnerable code, but also about dependability. Even if you ignore the “supply chain” security problems inherent in this model, it practically guarantees that the breakage you describe will happen eventually.
This is part of why I prefer languages with robust standard libraries, and why I am very picky about dependencies.
Thank god for proxy registries. I love Node, but it’s like using a house of cards as the foundation of a skyscraper.
The fact that NPM can’t use multiple registries (yes, I know about scoped registries) is astounding. For every other language my org will separate artifacts into half a dozen or so virtual repos. The artifact team is quite annoyed that Node/JavaScript has to all go into one uber-repo.
I personally don’t trust NodeJS libraries that much - I always run projects inside Docker as a regular user with access to the working directory, just in case the supply chain is poisoned.
In the case of Python, particularly when I was testing out the LLaMA model, I just stood up a new VM for that. Back then safetensors wasn’t a thing, and the model tensor file format (python pickle-based) could potentially store arbitary code.
Robust standard libraries are amazing to have.
What languages are those? And if you say C/C++ I’m going to laugh
The C++20 or so STL actually has things in it now.
It’s been better but still has a long way to go though, particularly regarding string handling
They still haven’t figured out string handling?
They’re all that way: it’s just that Node is automatic enough to notice more easily, plus had an insane number of small dependencies
We started doing vulnerability scans on every build, which sounds like a good idea. However, now I know: Java is exactly the same. We need to constantly update but all too often there is no update available yet
C# is also exactly the same, you just don’t get yelled at when things are out of date and you only see that if you go to manually install packages
In C# you can automatically generate (or manually write) binding redirects that let you say “anything using versions between x.y.0 and x.y.9 should use x.y.9”, which helps a lot with transitive dependencies. However, doing this manually is hard, and you can’t really rely on semver to be done “correctly.” This leads to subtle bugs. Occasionally not so subtle, but hard to diagnose.
I think NPM has the same feature, it’s called overrides https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v=true#overrides
For most projects or tools that I find on GitHub these days, I run them all in docker. Node, at least, is somewhat of a good guest. All it’s crap lives in node_modules, and so when I’m done, rm the directory and it’s all clean. Python seems to love leaving relics across my system
Welcome to my world. Not that I’m using node, but I’m using mediawiki. They manage to f-up something with about every update, and the documentation, if it exists at all, is often enough completely wrong or broken.
Been there, Mediawiki is truely painful, especially if you are trying to maintain an extension or two “on the side”.
That is exactly the case here. I’ve got a private wiki with a rather large extension by now, and it is the only PHP project I have. So whenever mediawiki f-cks something up, which is nearly every update, I restart my PHP skills to find and fix the sh-t they did to my code this time.
I wonder if it has something to do with the framework you pick. There are probably frameworks that aim to be as stable as possible but lack the cutting edge.
Deno solves this problem :)
Something in the dependency tree will yell at you that it is deprecated or discontinued.
Only if you didn’t pinned the dependencies you actually consume, and expect that all your dependencies magically comply with semver.
Blindly replacing dependency versions never worked, at least reliably. If you do not put in the work to ensure things work, more often than not you’ll be surprised by them not working.
Often it seems that people will make patch releases that add a “feature” of complaining at install time that that major release/minor release/entire package is bad now and should be replaced with something else. It still works, but it annoys everyone who transitively depends on it forevermore.
