While TypeScript seems to be a nice language, it's ecosystem is the JS ecosystem and it is madness.
Major versions of some common library breaking backwards compatibility released every week mean you need to run as fast as you can just to stay in place.
Public opinion can't be relied upon. The most popular ORM library just recently added support for native JOINs, and this wasn't common knowledge (I almost used it before at had them!). The most decent ORM as chosen by some coworkers very experienced with the ecosystem still doesn't support subqueries (well, there's an escape hatch for writing them in raw SQL...). Some marketer-turned-programmer created hundreds of useless packages (like, a separate package per ansi color) that all require each other, and they are popular enough that if you'll run npm ls in your real world project you will find that you depend on them.
Having professionally used cargo, pip, even cabal, npm feels like the eternal september of open source packages.
Most of the madness that you're describing there isn't inherent in the JavaScript ecosystem, it's more to do with undisciplined development practices that might be more likely to be enabled by JavaScript's flexibility but are by no means required in order to participate.
Don't use libraries that aren't stable. Aggressively trim dependencies. Lock versions and upgrade intentionally. Ideally, use a company registry to cache what you actually want to be using.
Every ecosystem has its problems, and JS+NPM's are largely that it's too good at making everything too easy, leading to an abundance of naive developers building in a naive way.
On the whole I'll take that over the unnecessary barriers in other ecosystems (don't get me started on pip...), but it definitely requires some discipline to navigate safely.
Can you recommend me basic libraries for full stack dev that don't suffer from this? At least logging, ORM, web request handling, authentication, sessions, bundling (edit: and middleware, because apparently that's a separate library).
In every other language I work in there are 1-2 libraries that cover all of this (except bundling which is only relevant to js) and don't require me to step on the versioning treadmill. If I had the same for JS, I'd be much happier writing typescript.
Edit: for example, this week I had to downgrade a dependency (middy) from v5 to v4 all across our services because jest doesn't support I think ejs well enough and v5 dropped support for all other ways to do modules. It tooks hours of fighting to find the right combination of deleting the lock file, deleting various node_modules dirs and running npm i that actually replaced the installed v5 with v4.
you can get lucky and reach a nirvana state where all your dependencies function well in a new project, but 6 months later its a disaster like ah you need to upgrade node, but ah your transpiler requires the older version of node, but ah the semantic versioning was not followed by your type definition addendum library and now there were autoupdated breaking changes, ah your project only worked with a locked package file and if you re-install any package the wrong way everything breaks in incomprehensible ways!
I know my way around it though, so yay big bucks and quick deployment of greenfield projects
I know this isn’t realistic for many many scenarios, but if you can help it there is a sweet spot where you dedicate ~30 minutes to merge weekly dependabot updates and you don’t run into this problem.
Major versions of some common library breaking backwards compatibility released every week mean you need to run as fast as you can just to stay in place.
Public opinion can't be relied upon. The most popular ORM library just recently added support for native JOINs, and this wasn't common knowledge (I almost used it before at had them!). The most decent ORM as chosen by some coworkers very experienced with the ecosystem still doesn't support subqueries (well, there's an escape hatch for writing them in raw SQL...). Some marketer-turned-programmer created hundreds of useless packages (like, a separate package per ansi color) that all require each other, and they are popular enough that if you'll run npm ls in your real world project you will find that you depend on them.
Having professionally used cargo, pip, even cabal, npm feels like the eternal september of open source packages.