Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A JavaScript Nightmare

blog.ignaciobrasca.com

Post reply on HN
Print view View original

41–50 of 101 posts

Re: A JavaScript Nightmare

#41

Post by rezonant »

crummy wrote: post #14
wiseowise wrote: post #8

> not using TypeScript for any serious product Well, here is your problem.

Would Typescript have solved this though? They still would have been using npm etc

Yes it very likely would have. Most libraries have their types shipped alongside the JS, and if that's where the change was, it would have been caught during build. I'd argue that even if the types for the changed package were from DefinitelyTyped, it probably still would have solved the issue if the developer had just blindly updated some package versions-- they likely just upgraded everything, ignoring semver.

Re: A JavaScript Nightmare

#42

Post by skyguy94 »

stana wrote: post #22
MrJohz wrote: post #18

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…

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.

This exactly. Javascript needs a standard library.

Re: A JavaScript Nightmare

#43

Post by brazzy »

yen223 wrote: post #11
pier25 wrote: post #10

Earlier 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!

>The only change that isn't "breaking" is one that only adds functionality.

Ha! Think again. On of the more annoying problems I had to analyze was when a new PHP version added a function that already existed in my application (this was before namespaces). The runtime did not like that.

Re: A JavaScript Nightmare

#44

Post by golergka »

MrJohz wrote: post #18

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 deleted all cache on my local environment, all node_modules references, all lock files. I ran an installation process once again and exported again… it didn’t work.

> The next message I sent: “We found it!”

May be I misunderstand something, but from the post it sounds that they don't even commit their package-lock.json. They're using node like its 2012.

Re: A JavaScript Nightmare

#45

Post by atoav »

peschu wrote: post #37
MichaelRo wrote: post #12

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 called „motivation“

Jup, and if your employer doesn't stop you or even expects such behavior that is called a bad work culture.

Sure, I would also do long programming sessions on my own things every now and then, but those happen because I am in the flow and it feels like more work to come back into it the other day. But those are my own projects. I don't owe this to my employer. If they want that they could offer me double my current salary and even then I would insist on only doing it when it makes sense to me.

Re: A JavaScript Nightmare

#46

Post by rezonant »

grujicd wrote: post #36
wiseowise wrote: post #25

Earlier quoted context omitted.

> this.subset.encodeStream is not a function Yes?

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.

Sounds to me like you are missing types or the types you have are incomplete.

When you do things correctly, this is not an issue. Part of doing things correctly is preferring (and in some cases requiring) that your dependencies either be written in Typescript or at least ship the types directly in the NPM package, per best practice.

Re: A JavaScript Nightmare

#47

Post by PUSH_AX »

wiseowise wrote: post #40
PUSH_AX wrote: post #32

Earlier quoted context omitted.

This was a runtime issue in a third party lib, so no.

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.

Re: A JavaScript Nightmare

#48

Post by rezonant »

wiseowise wrote: post #8

> not using TypeScript for any serious product Well, here is your problem.

Exactly.

I'm not sure where that quote comes from, but these days in terms of TS vs JS it's 100% "not using untyped JavaScript for any serious product".

Re: A JavaScript Nightmare

#50

Post by rendall »

PUSH_AX wrote: post #32
wiseowise wrote: post #25

Earlier quoted context omitted.

> this.subset.encodeStream is not a function Yes?

This was a runtime issue in a third party lib, so no.

Maybe? The discipline of using typecript and carefully distinct commits might not have solved this particular problem, but I suspect a team that does this would not be facing this issue as a Friday night 10 hour debugging session.
Post reply on HN