51–60 of 101 posts
Earlier quoted context omitted.
Would Typescript have solved this though? They still would have been using npm etc
> this.subset.encodeStream is not a function Yes?
So all the dependencies would need typescript?
The article is not very concrete in what was the actual bug
- Use Typescript.
- Practice version locking on your dependencies and make sure it works correctly throughout your processes
- Do not commit vendored dependencies
- Do not commit compiled JavaScript
- Use a CI process for deployment which runs your tests
- Have tests
- Prefer (or require) types for your dependencies, or dependencies written in Typescript
- Prefer dependencies that ship the types in package (and not via DefinitelyTyped)
Some additional thoughts, they act like running out of memory is something they need to actively handle in the codebase-- it's not in this case. It shows a lack of familiarity with how JavaScript runtimes work which hints at a team which is very inexperienced with the platform. JavaScript runtimes enter GC lockup and ultimately crash if there is no memory, so this is a logging problem, not an error handling problem. There is no mechanism for the runtime to inform the app that an allocation failed.
This 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…
I didn't quite understand why they had to debug on the spot, thus working like 36 hours uninterrupted or so. A sane working environment would file a priority 0 bug and address it during working hours. I'm not throwing a rock but oftentimes this sort of heroic behavior is self-inflected. Also why is heroic debugging required on something that is not production? The article mentions it was a "quick demo". Then who give…
It's really strange that they would invest all this time as if they are keen to understand the cause of why it happened, but then be satisfied when jiggling the handle solved it. The real cause ultimately is a process one (developer discipline) or a pipeline one (bad build/test/deployment processes). They got close to realizing it and then blamed the language instead of what appears to be bad practices happening on their dev team.
This was posed 20 hours ago: https://news.ycombinator.com/item?id=39724247 Not sure why I can't downvote articles, ah well.
Earlier quoted context omitted.
TypeScript types work only on compile time. If library changes without changing its public TypeScript signatures it won't help at all. Also, after coming from real compiled languages I find TypeScript ecosystem not to be robust at all. Change in one file sometimes does not result in compile time error in another file where changed type is used. Yes, it's not an issue with TypeScript itself but with its ecosystem, tra…
The types should be shipped with the code which is nearly ubiquitous for NPM packages these days (at least the ones you should actually be using). If they were, you would catch the issue as soon as you built the app, which should be happening in a CI or deploy process (never commit your compiled code). > Change in one file sometimes does not result in compile time error in another file where changed type is used. Sou…
I'm not talking about npm, I experienced these issues in my own code. It's mostly related to ts transpilers. They're fast, they're used in build systems which should be latest and greatest (e.g. Vite), but they're not robust, they don't always catch type changes in dependent files. And now I can't just change a type and rely on compiler to check ALL occurrences in entire code base. Because it's not really a compiler but a transpiler and it misses some things. Also, tsc doesn't seem to handle jsx/tsx, is there a way to perform real type script compilation with full type checks on tsx files?
Earlier quoted context omitted.
If the library used TypeScript, it wouldn’t have the issue. The point still stands.
Debatable, and I don’t know how that helps the author. I’m getting huge “silver bullet” sentiment from your replies too.
> getting huge “silver bullet” sentiment from your replies
???
> 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, b…
tldr: A dependency wasn't pinned, the dependency changed, and stuff broke. Author thinks Javascript sucks. I will say this though: it is infuriating that package managers (every single one I've used, not just NPM) don't default to pinning exact dependency versions, and instead let it "automatically" update minor versions.
If you listen to very bad advice though, half of the Q&A answers on the Internet suggest all problems can be solved by deleting package-lock.json, to be fair.