|
Studying the dependencies, esp for JS, takes a lot of time as well. Before including a library, I want to know if it is maintained, if it has no known sec flaws and if the author dies I have a chance of taking it up ourselves, at least for audits and sec fixes. If you are doing npm install and further ignoring those implications, then yes, you are right, but it will bite you in the end as software outlives it’s initial intended lifespan sometimes by decades; how much VB6 is running production that was ‘just a little tool for a few months until we ...’? ... how much PHP? personally I know 1000s of those running across companies we work with. With VB6 and PHP ‘oldskool’ (meaning little or no deps in the form of downloaded libs and components) people have no issue maintaining it. But if you have to do some fixes in 2029 on a node.js API you finished yesterday, you would not be happy. With 10000s of libs that will not exist anymore, many of those having massive security issues, many API’s they call out to having changed, you would need to study and work on the entire tree that affects the changes. If you did not set this up with this in mind (which seems some kind of JS plague as you indeed also suggest), this is what will happen in many occasions. In general; many deps is a bad idea for longevity of software. How can you know if it does not all crash and burn if the author changes jobs? Personally I want to know I have the sources and understand them enough to be able to support them with our team; in reality, for the JS ecosystem, that often means it is less work (those hours you mention) to write it yourself because it was trivial to begin with anyway and the npm solution has 1000 dependencies yours does not (for instance, they use deps like left-pad to implement something that can be implemented in 100 lines of pure JS, now needing still 100 lines but of rancid (unsupported?) one liner ‘libraries’ which is absolutely insane) Managers usually are not programmers nor have technical background: once something works, they might not allocate time for you/your team to touch it for many years. You probably left or enjoying your pension (many anecdotes about that: a lot of companies are running on software that was done by one employee and he retired, years ago), while some poor junior who does not know what JS is, is holding your turd. At least with 20 year old PHP it still runs and without knowing PHP beforehand, it is not hard to change/fix for a capable programmer. I have seen this with larger node.js and with Rails projects; not so much with Java and .NET projects; the latter seem to be fine many year later (maybe with some tiny migrations), even when updating libraries or runtimes. It is a compromise ofcourse; I am not against reuse, but only to the limit we could possibly handle maintenance and updates ourselves of all imported libs. Otherwise it is a no-go. |
many of these only work when installed globally and conflict each other version to the point the only way to work at project of different ages are chroots or flat out vms. whomever ever thought that -g was a good idea should never work at a tooling system again.
heck, some years ago you could push a library change to npm updating a version number that already existed there, the place is a mad house.