Eh, no. You'll get shot no matter what, even if you have no gun.
For example, let's imagine you now have your version locked down codebase and after a month you want to install a new package. This one is only compatible with XYZ V1 while what you have is V2. No worries, npm will just handle that right? Well, you'll have both versions, but the prototype constructor name changed from V1 to V2, so the versions won't work together, so now you need to upgrade XYZ V1 everywhere anyways. And when XYZ did the V1->V2 upgrade, they also upgraded to GKS V53, so now you need to also do that upgrade.
Continue ad-infinitum or simply stay away from a broken ecosystem.
On the JS side there's a way deal with that if people use modules. Good dependencies don't clobber the global namespace. Multiple versions can exist side by side. It'll just make your build bigger.
If you absolutely need to have multiple versions of the same dependency, you probably need to use OSGi.
What's your point? If you want to update a dependency then you also need to go through all their dependencies. This is not a javascript/npm problem; it's a software development problem. Dependencies don't get magically updated, even with semver. You experience the exact same problem with other tech stacks. I'm fact, I've experienced this problem far more with C++ projects than with JavaScript/typescript ones.
Why are we expecting and demanding random updates to work with JavaScript/npm when that belief and expectation was always totally unrealistic with any other stack?
I'm not sure you're thought things through in your comment, and that you are being fair or reasonable.
No one cuts "everything into mini dependendencies". You have dependencies you reuse. That's it. When one of those dependencies gets updated, say to fix a bug or a security issue, your package manager of choice handles it for you without any issue. Still, if you do not want to fix bugs or vulnerabilities in your code then you are free to pin them all and move on with your life.
At most, the JavaScript or NodeJS crowd needs to have a serious talk about standard libraries and third party lackages, such as whether using packages such as rimraf is desirable.
> and yarn/npm frontend projects that cant be even rebuilt two weeks later
You only experience that sort of problem if you're incompetent in how you manage your dependencies.
With npm you can a) pin major/minor/patch versions of specific packages, b) save your package-lock.json file which specifies exactly which dependencies you use. If you free-float any dependency then that's something you chose to do.
With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard.
> And I m very against transpilers and linters which I try to avoid for sanity (...)
Complaining about linters because they test your sanity is a major red flag on your approach to mundane coding tasks. This, and your casual criticism on everyone else's code, leads me to suspect that you really need to do some introspection.
> I kid you not we have an entire team in charge of one small frontent management tool for a pretrade backend, they literally spend 99% of their time justifying why they wont change it, and 1% begging me to join for a week to reorder their column or put a new button...
Based on your comment and on my experience with similar projects, I suspect you're either oblivious and/or leaving out important bits of the story just to continue plowing with your humblebrag, or you're succumbing the need to be hyperbolic.
Frontend development has to deal with far more details and constraints and requirements than any backend task. Frontend is what both clients and PMs and executives look at, and the tiniest changes like resizing a button has deep implications on the business side of things. Furthermore, it's both harder to automate tests and their tests need to be more extensive.
Thus any change, no matter how small, is a uphill battle.
It's beyond me how someone who is so hard on their entire team ends up showing such weak understanding and insight of the problem domain. I know that on the internet no one knows you're a dog, but let's not get silly here.