The real question the OP should be asking is not which language to use, but how this change managed to pass unit and e2e tests and be deployed to master in the first place. Fair enough javascript has its sharp bits, but those should show up in proper commercial level of unit and integration testing.
A JavaScript Nightmare
81–90 of 101 posts
Re: A JavaScript Nightmare
#82Earlier quoted context omitted.
Last time I know during node 16, npm install updates your package-lock.json, but for patch version number (unsure about minor version) only and if the package.json is using relative version number. Definitely use npm ci or yarn if you want to adhere to lock files.
> if the package.json is using relative version number What do you mean by this? You can specify dependency versions using "^" which means "I accept new minor and patch versions" or "~" which says "I accept new patch versions", or a bare version to say I want an exact version; but none of those have anything to do with a bare "npm install" command. They are relevant when you install a new package, with "npm install "…
Exactly what I said, I have experience with ~ but not with ^ and have never used it. Let's say that you have a package version ~1.2.11 and have 1.2.11 as installed version in package lock. Then if let's say 1.2.13 is out there, npm install will update package lock to that one. npm ci won't change that. package.json file will kept unchanged though.
Re: A JavaScript Nightmare
#83JavaScript A Nightmare
Re: A JavaScript Nightmare
#84Earlier quoted context omitted.
> if the package.json is using relative version number What do you mean by this? You can specify dependency versions using "^" which means "I accept new minor and patch versions" or "~" which says "I accept new patch versions", or a bare version to say I want an exact version; but none of those have anything to do with a bare "npm install" command. They are relevant when you install a new package, with "npm install "…
Exactly what I said, I have experience with ~ but not with ^ and have never used it. Let's say that you have a package version ~1.2.11 and have 1.2.11 as installed version in package lock. Then if let's say 1.2.13 is out there, npm install will update package lock to that one. npm ci won't change that. package.json file will kept unchanged though.
No, "npm install" doesn't actually do that. In the situation you are talking about, "npm install" and "npm ci" behave the same.
It makes sense that they behave the same here right? What is the point of a package lock if just installing packages on a new copy of a codebase updates the dependencies?
Package locks aren't just about deploying: As a developer, I need to be assured that the code I'm running is the same as my coworker.
Re: A JavaScript Nightmare
#85Earlier quoted context omitted.
Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a lot. It is definitely a language that is focused on correctness and convenience. That being said, there isn't too much about Kotlin I miss when I write Typescript in strict mode. > Unlike typescript, it does not really have a non strict mode (except for the d…
Strictness should not be optional. A lot of typescript projects don't use all the features. I've been on projects where people were just working around those features to do all the crazy hacks javascript is famous for; or to be able to use libraries that use those hacks. It's a constant fight to push back that madness. With Kotlin, that's just much less of a concern. Having a language that just says no to all of that…
Well, strictness actually is optional in Kotlin too, since you can lateinit things and !! your way through nullability like in any language. And of course if you are consuming Java stuff this is more likely, since Kotlin exposes nullable types for everything in Java, so sometimes the right call is to non-null assert since the interface you are consuming can't represent non-nullability.
Re: A JavaScript Nightmare
#86Earlier quoted context omitted.
Agreed, when they popped out this "such and such isn't a function" I lost the thread. You would know about that before you even started if you just read some logs. Unless they don't have logs, in which case a choice of language isn't going to solve their problems.
Or not handling uncaughtException or unhandledPromiseRejection, which may be common mistakes.
Handling uncaughtException and unhandledPromiseRejection is a common mistake. You should not do it unless you have a good reason. Your program should die for science, and you should fix the place where you didn't handle that exception or rejection.
Unless of course your handler results in dying for science, then it's fine (ie for sending to an observability service first)
Re: A JavaScript Nightmare
#87Earlier quoted context omitted.
Or not handling uncaughtException or unhandledPromiseRejection, which may be common mistakes.
Handling uncaughtException and unhandledPromiseRejection is a common mistake. You should not do it unless you have a good reason. Your program should die for science, and you should fix the place where you didn't handle that exception or rejection. Unless of course your handler results in dying for science, then it's fine (ie for sending to an observability service first)
Yes, though you still log them though and then exit the program
Re: A JavaScript Nightmare
#88Earlier quoted context omitted.
Handling uncaughtException and unhandledPromiseRejection is a common mistake. You should not do it unless you have a good reason. Your program should die for science, and you should fix the place where you didn't handle that exception or rejection. Unless of course your handler results in dying for science, then it's fine (ie for sending to an observability service first)
Yes, though you still log them though and then exit the program
Ninja'd, see my edit. Fine to log and die if needed of course
Re: A JavaScript Nightmare
#89Earlier quoted context omitted.
Exactly what I said, I have experience with ~ but not with ^ and have never used it. Let's say that you have a package version ~1.2.11 and have 1.2.11 as installed version in package lock. Then if let's say 1.2.13 is out there, npm install will update package lock to that one. npm ci won't change that. package.json file will kept unchanged though.
No, "npm install" doesn't actually do that. In the situation you are talking about, "npm install" and "npm ci" behave the same. It makes sense that they behave the same here right? What is the point of a package lock if just installing packages on a new copy of a codebase updates the dependencies ? Package locks aren't just about deploying: As a developer, I need to be assured that the code I'm running is the same as…
Hmm weird, I remember it changed on the older version though, which is why npm ci is introduced.
Re: A JavaScript Nightmare
#90Earlier quoted context omitted.
No, "npm install" doesn't actually do that. In the situation you are talking about, "npm install" and "npm ci" behave the same. It makes sense that they behave the same here right? What is the point of a package lock if just installing packages on a new copy of a codebase updates the dependencies ? Package locks aren't just about deploying: As a developer, I need to be assured that the code I'm running is the same as…
Hmm weird, I remember it changed on the older version though, which is why npm ci is introduced.
Yes I think you are right when NPM first introduced it, which was in NPM 5 [1]. At that time package locks were new.
Node 16 shipped with NPM 8, and by then this was not the behavior any more. I don't remember exactly when, but I believe it might've been in NPM 7 when this changed. Node 15 would have been the first release to ship with at least NPM 7 [2]
EDIT: Node 16.0.0 shipped with NPM 7.8.0
https://github.com/nodejs/node/blob/main/doc/changelogs/CHAN...
EDIT 2: A StackOverflow confirming NPM 5 behaved the way you remember: https://stackoverflow.com/questions/45022048/why-does-npm-in...
EDIT 3: And, as that SO documents, 5.4.2 changed the behavior to prevent this, here's the GitHub issue: https://github.com/npm/npm/issues/17979#issuecomment-3327012...
Honestly no guarantees it worked as intended right at that release, but the intention is clear.
EDIT 4: I realize that the following may present retort but it matches my mental model perfectly:
> If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.
This is what I've mentioned elsewhere: You should not update package.json's versions and deploy it and expect that versions won't change when NPM install runs. In fact, npm ci will just fail in this situation, which is a Good Thing (TM), and is documented as such.
LAST EDIT SRSLY:
It is conceivable, especially given OPs other red flags, that perhaps they were on an older Node/NPM like Node 14.
That's another practice that I regularly do, pin NPM itself in deploy scripts. While I was using Node 14, I was using NPM 8, because you can just "npm i npm@8 -g" to upgrade your NPM regardless of Node version.
[1] https://blog.npmjs.org/post/171556855892/introducing-npm-ci-...