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.

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.

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.

Ouch, if you're using gulp/grunt/browserify or anything that wasn't invented six months ago then you're doomed anyway :)

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/

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.

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.

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.

> 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.

Publishing & importing 3rd party code is so easy with npm that everyone is blindly importing code that wouldn't pass their own peer reviews.

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.

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?

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