This was very funny to read because as someone who is actually familiar with these JS builds I immediately guessed that a dependency had changed. That's literally the first thing I'd check if an app is behaving differently in a remote environment than it is locally. I'd recommend the OP learn some JS best practices and apply them rather than complaining that JS isn't C.
A JavaScript Nightmare
21–30 of 101 posts
Re: A JavaScript Nightmare
#22This is the second time I've ended up reading this post, and I confess I still don't exactly understand what was going on here. There's an issue with PDFs missing their contents, but also timeouts and a missing method exception? The problem seems to have come from upgrading some dependencies at some point, but the solution is also an upgrade, as far as I can tell? And then the cache issues at the end sound very much…
Stuff that gets pulled in when you do 'npm install' is scary for a more traditional server-side developer. Python for example comes with a lot of built-in libs maintained by the core python team. These could get you pretty far before you start pulling in libs from random authors.
Re: A JavaScript Nightmare
#23The problem philosophy that a few HTTP requests need to be wrapped in a library that includes hundreds of other libraries is not a JavaScript problem. It's a social problem.
Re: A JavaScript Nightmare
#24Re: A JavaScript Nightmare
#25Re: A JavaScript Nightmare
#26Re: A JavaScript Nightmare
#27Why didn't you check the logs as the first thing to understand what's happening -- a standard operational practice?
And then to prevent this, you just lock the dependencies via a lockfile -- a well documented solution.
This is just another amateur "javascript bad" post.
Re: A JavaScript Nightmare
#28> One tiny version mismatch or breaking change can bring your mission-critical application to a standstill, as we painfully experienced. This is true in many other languages, not just Javascript. This isn't a "Javascript nightmare", this is a dependency nightmare.
In a statically compiled language, when APIs change, you get compile errors that show up at build time. It's usually pretty obvious. With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed. That combined with poor test coverage means a lot of potential for things to slip through build and QA processes.
I use Kotlin, both on the JVM and in the browser (via kotlin-js). Dependencies are equally complex as in javascript but it's much easier to find out if stuff breaks or not. I update often to minimize the amount of changes I have to deal with. This may sound counter intuitive but integration testing small deltas is exponentially easier and less risky than big deltas.
My attitude to having big updates lurking is that they represent technical debt. Just because you don't know you have a problem because you haven't updated yet doesn't mean you don't have a problem. By not updating, you just increase your ignorance of technical debt. It might be piling up without you realizing. And you might be making things worse by working against obsolete APIs.
Upgrading libraries often means I typically only have to deal with a handful of minor updates for libraries that are mostly unproblematic. And if stuff breaks, it's easier to pin point the source of the breakage. And I find out as early as possible about problems I need to deal with. If I don't know about it, I can't deal with it either. Sometimes downgrading a library temporarily is needed. But then you document why and stay on top of issue trackers and upstream development to see when you can upgrade or you start looking for alternatives.
Occasionally, some API breaking changes happen and then I fix it (because the compiler tells me stuff is not compiling). If I don't update for a year, I probably have a lot of breakage on my hands and a lot of work fixing things. Much harder and much more time consuming. And risky. All I know then is that I probably have a lot of problems (i.e. technical debt) on my hands that I don't know about.
Re: A JavaScript Nightmare
#29> @smithy/util-stream@2.2.0
> @smithy/is-array-buffer@2.1.1
Are these direct deps? Because just a cursory look raises all kinds of red flags. There's a disclaimer for the former warning about it being in developer preview, and the rest of the README has a bunch of notes about edge cases.
I get that the aws-sdk uses them, but if it works for other people it should be fine. Having these as direct deps and also calling in complex libs like the aws-sdk honestly seems like a recipe for disaster.
Re: A JavaScript Nightmare
#30Earlier quoted context omitted.
The package wasn't following semantic versioning. Only major versions should introduce breaking changes.
The only change that isn't "breaking" is one that only adds functionality. Otherwise, it changes behavour, and has the potential to break your software. In practice, almost all changes should be major version bumps. Anyway that's besides the point. Let me control when version changes happen!
I used to maintain some open source libraries and absolutely no change we would release would break anything and definitely not over a minor version. We even did a major rewrite that completely changed the API and we broke nothing, but it did mean your project got a lot of deprecation errors.
And our docs would mention both the old and new way so if you were searching the Internet for help, you wouldn't get confused when you saw wildly completely examples.
It's all about craftmanship.