5 ms·

> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A does

> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D. Then you need to repeat this every few months because there's nonstop vulnerabilities flagged and APIs broken. Nah, I'm good.

quonn 3y ago
Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.
- jacobyoder 3y ago
  > Nobody says you need to install hundreds of packages. If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control. Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief. FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.
  - cryptonym 3y ago
    Publishing & importing 3rd party code is so easy with npm that everyone is blindly importing code that wouldn't pass their own peer reviews.
- stiiv 3y ago
  Agreed! For this reason, we use very few third-party dependencies in our big TS monorepo. NPM is a jungle, and for an experienced team of TS developers, a new dependency just isn't worth the risk -- we'd rather just code things ourselves. But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.
donatj 3y ago
This is exactly what we’re dealing with right now trying to upgrade TypeScript. We’re stuck on an early version of 4.X because of some dependency triangle I haven’t had time to work out.
- marius-sw 3y ago
  Hello, I have nearly 10 years of experience dealing with this. Do you need help? I am sure I could fix it in a few hours - either I fix it within 5 hours or you don't pay anything. My hourly rate is 150 EUR and my email is in my profile.
  - donatj 3y ago
    No disrespect but frankly I don't think you could, I don't think anyone could. It's a giant tangle of grunt and require and special custom build systems.
    - mortallywounded 3y ago
      Ouch, if you're using gulp/grunt/browserify or anything that wasn't invented six months ago then you're doomed anyway :)
- alexpetros 3y ago
  I am always perplexed by how many people deny the reality of this. Upgrading TypeScript major versions for any package of non-trivial size and dependencies is often (not always, but often) quite difficult! I wrote about that in my last htmx essay.[0] [0] https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/
iterateoften 3y ago
Seems a bit of an over reaction. Never experienced anything like you say since working with typescript after working on multiple billion+ $ SaaS apps. It’s basically the same as any other language.
- infamia 3y ago
  Did you not deal with the debacle of js changing imports how imports work? That was absolutely miserable and js libraries have a very short half life indeed. JavaScript's culture of small, relatively short lived libraries makes maintaining a JS app particularly miserable for many (see the comments affirming this misery). It is not anything close to the same.
kugelblitz 3y ago
Yeah, as a full-stack / backend developer using PHP / Symfony (and Twig), I only occasionally need to update the frontend. But then all these problems keep popping up. Oh, that's the wrong yarn version. Oh, I thought v3 is the newest? But we still use v1? I used v3 in another project. So I need to install different versions? Ah, then I also need different versions of node? Ah, better to use nvm? Because only later versions have corepack, the experimental but recommended tool? Or do we change back to npm? And why does an install process change a .lock file?
mortallywounded 3y ago
This is such a common issue with npm and bundler it was an inside joke/meme at every company I worked at. Person A: "Hey, so I ran bundle update and it's not working." Person B: "You updated the dependencies? WHY WOULD YOU DO THAT!"

quonn 3y ago

Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.

jacobyoder 3y ago
> Nobody says you need to install hundreds of packages. If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control. Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief. FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.
- cryptonym 3y ago
  Publishing & importing 3rd party code is so easy with npm that everyone is blindly importing code that wouldn't pass their own peer reviews.
stiiv 3y ago
Agreed! For this reason, we use very few third-party dependencies in our big TS monorepo. NPM is a jungle, and for an experienced team of TS developers, a new dependency just isn't worth the risk -- we'd rather just code things ourselves. But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.

donatj 3y ago

This is exactly what we’re dealing with right now trying to upgrade TypeScript. We’re stuck on an early version of 4.X because of some dependency triangle I haven’t had time to work out.

marius-sw 3y ago
Hello, I have nearly 10 years of experience dealing with this. Do you need help? I am sure I could fix it in a few hours - either I fix it within 5 hours or you don't pay anything. My hourly rate is 150 EUR and my email is in my profile.
- donatj 3y ago
  No disrespect but frankly I don't think you could, I don't think anyone could. It's a giant tangle of grunt and require and special custom build systems.
  - mortallywounded 3y ago
    Ouch, if you're using gulp/grunt/browserify or anything that wasn't invented six months ago then you're doomed anyway :)
alexpetros 3y ago
I am always perplexed by how many people deny the reality of this. Upgrading TypeScript major versions for any package of non-trivial size and dependencies is often (not always, but often) quite difficult! I wrote about that in my last htmx essay.[0] [0] https://htmx.org/essays/no-build-step/ https://htmx.org/essays/no-build-step/

iterateoften 3y ago

Seems a bit of an over reaction. Never experienced anything like you say since working with typescript after working on multiple billion+ $ SaaS apps. It’s basically the same as any other language.

infamia 3y ago
Did you not deal with the debacle of js changing imports how imports work? That was absolutely miserable and js libraries have a very short half life indeed. JavaScript's culture of small, relatively short lived libraries makes maintaining a JS app particularly miserable for many (see the comments affirming this misery). It is not anything close to the same.

kugelblitz 3y ago

Yeah, as a full-stack / backend developer using PHP / Symfony (and Twig), I only occasionally need to update the frontend. But then all these problems keep popping up. Oh, that's the wrong yarn version. Oh, I thought v3 is the newest? But we still use v1? I used v3 in another project. So I need to install different versions? Ah, then I also need different versions of node? Ah, better to use nvm? Because only later versions have corepack, the experimental but recommended tool? Or do we change back to npm? And why does an install process change a .lock file?

mortallywounded 3y ago

This is such a common issue with npm and bundler it was an inside joke/meme at every company I worked at. Person A: "Hey, so I ran bundle update and it's not working." Person B: "You updated the dependencies? WHY WOULD YOU DO THAT!"