zlacker

TypeScript is really nice though.

>>odie55+(OP)
> TypeScript is really nice though.

Even if that's true, it is irrelevant.

  - You need to decide package manager and everyone has their favorite one: npm, yarn, bun, pnpm ...
  - You need to depend on npmjs.com for dependencies, which has an unusually high number of malicious packages compared to other dependency sources.
  - You need to use some framework like Next.js, which itself is a cesspool of backward-incompatible changes, combined with outrageous security issues

>>odie55+(OP)
... if your baseline is JavaScript.

>>ashish+W7
If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits.

Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use.

Bun also allows for this but it feels a bit more tacked-on and less like an early architectural decision based around security concerns.

>>steve_+AI1
> If you use deno you can consume dependencies much more securely

How would Deno have prevented the RCE issue with React+Next.js?

>>ashish+Wk2
It wouldn't. I was responding to your concerns about the TypeScript ecosystem more generally.

You avoid the RCE by recognizing that React—and more recently Vercel's—management is a bit of a tire fire, and you should choose better tools with more responsible maintainers.

Part of what bothers me about this situation is that React appears to be a view library, and to many people using it that is what it functions as... But it's now a framework which extends well beyond the browser and entails all kinds of security risks that aren't intuitive at a glance, at all. A lot of people using Next probably have no idea about the security implications of the framework or how React fits into them. It's a mess.

Deno definitely can't fix that.