Lately I've been using gradle with kotlin-js and a mix of npm and jvm dependencies. There's the https://splitties.github.io/refreshVersions/ plugin that I can recommend if you are using gradle (with or without kotlin-js).
It manages plugin dependencies, library dependencies, and version dependencies. It can use the new gradle version catalog or not if you prefer. On first use, you migrate your versions and it extracts these to a versions.properties (or your version catalog). Then whenever you run refreshVersions it indicates available new versions in comments in this file. It also indicates unused dependencies. Though for npms this is a bit harder. All you need to do is manually use the versions you want.
I run this frequently to stay on top of upstream changes. Few software engineers realize that the testing and integration overhead with version changes multiplies (just like with other forms of change). Libraries that you haven't updated amount to technical debt that you haven't addressed. So, the workload increases massively if you don't update for a while. Staying up to date minimizes the workload. This plugin makes that super easy.
Given that we are using kotlin-js, we have to deal with a rapidly evolving library ecosystem so we do have occasional issues that we need to work around by either downgrading or fixing some code. Whenever I can't update something, I document it in my versions.properties with a comment. Often you just have to wait for the next release or so for things to straighten out. The price of using cutting edge software.
Kotlin-js manages a yarn lock file as well. So it properly locks dependencies. Whenever you update npm dependencies, you have to run a command to upgrade the lock file. There's also a whole mess of webpack dependencies that comes along with kotlin-js.
You can get so much done with the basic supplied libraries when programming for .Net, JVM or Cocoa. What a giant leap back we made in terms of ecosystem and language by going for JavaScript everywhere.
I first used Node around 2010 to write some little TCP servers and local event processing tools. It was fun and simple with just the standard library, and I remember thinking:
"A great thing about this Node package manager is that it's obviously so intentionally primitive, nobody would try to use it to create those massive framework dependency monsters like in other languages. So this will remain a simple and fast runtime."
How profoundly wrong I was (not for the first time).
Goddamnit, the JavaScript ecosystem needs its own Visual Basic. Something that comes with everything you need to build and deploy a basic, but functional, real-world application.
* Any dependencies need to be installed to build a real world (server + UI or API) application = non-starter.
* Any shell commands needed to write, build, or deploy the app in a container = non-starter.
* Any code necessary to lay out the UI (including HTML, CSS) = non-starter.
I haven't kept abreast with the Microsoft ecosystem. Does Visual Studio have something like this for Node apps? Is ASP still a thing for C#?
Exactly, front end coders are very design driven (obviously) so they often value "ooh the shinies" brand new framework, etc over "let's engineer this correctly" battle tested not so shiny code.
I understand the Javascript fatigue, but why going for Javascript everywhere ? Keep it where it belongs, in the browser, then it's not so bad (or rather, it is bad but it's getting better).
Personally I have gone for golang everywhere; via WASM. The golang standard library is much cleaner than the Javascript ecosystem and in almost all ways is performant under WASM. Obviously you also get the benefit of having the same code on the server and the browser. You can't avoid the DOM, but you can do some pretty amazing things with SVG if you take it easy (browsers are renowned for their inefficiencies with too many SVG images on a page). For most web sites it's a good fit. And unlike Javascript golang heavily leans you toward doing the right thing (although you can always stuff things up if you try). The only real pain point is that WASM is still finding its feet.
I can't share any of my own examples, but most of the work I do was originally based on Vugu[0] which is open source. It is loosely modelled on Vue, so template files have both HTML and Go source (for the view / front end / ui handling) in the one file.[1] The code I have written has since diverged a bit from Vugu but at its core it's handled the same way.
People are still working on Vugu (you can check the issues / branches) but there hasn't been a new release in a while; it's still somewhat experimental.
Npm and yarn can't garbage collect transitive dependencies once they're unreachable from the explicitly installed roots? I think apt could do that since forever ago (with apt-get autoremove).
Maybe the officially supported way to prune the dependency tree is to blow away node_modules and then do npm install or yarn install. How stone-knives-and-bearskins.
It manages plugin dependencies, library dependencies, and version dependencies. It can use the new gradle version catalog or not if you prefer. On first use, you migrate your versions and it extracts these to a versions.properties (or your version catalog). Then whenever you run refreshVersions it indicates available new versions in comments in this file. It also indicates unused dependencies. Though for npms this is a bit harder. All you need to do is manually use the versions you want.
I run this frequently to stay on top of upstream changes. Few software engineers realize that the testing and integration overhead with version changes multiplies (just like with other forms of change). Libraries that you haven't updated amount to technical debt that you haven't addressed. So, the workload increases massively if you don't update for a while. Staying up to date minimizes the workload. This plugin makes that super easy.
Given that we are using kotlin-js, we have to deal with a rapidly evolving library ecosystem so we do have occasional issues that we need to work around by either downgrading or fixing some code. Whenever I can't update something, I document it in my versions.properties with a comment. Often you just have to wait for the next release or so for things to straighten out. The price of using cutting edge software.
Kotlin-js manages a yarn lock file as well. So it properly locks dependencies. Whenever you update npm dependencies, you have to run a command to upgrade the lock file. There's also a whole mess of webpack dependencies that comes along with kotlin-js.