I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)
replyI previously worked at Deno and even with all that tbh, I am not sure the http deps were the right way to go. I've really wanted to like them but package managers really have advantages.
replyI would not say npm was the right direction. I actually was a fan of JSR (didn't work on it but all my experience with it was great)
As someone that works in projects with standard IT tools, not supporting NPM made it a non starter for us.
replyNo way it would go through standard build pipelines, or team skills.
Oh, for sure. But I'm old enough to remember when standard IT tools would have never supported Node in the first place and the idea of JS on the server made everyone scream. You just need to build demand for that support.
replyFor us the demand is, does it run everything that either Angular or Next.js require, or the SDKs from headless SaaS products.
reply"standard" IT tools?
replyYes, IT from customer, or agency delivery operations, dictates what are the official tools in specific projects, including 3rd party dependencies in internal repos, and CI/CD is cut off from accessing public Internet.
reply