Today, we’re thrilled to announce Deno 2, which includes:
- Backwards compatibility with Node.js and npm, allowing you to run existing Node applications seamlessly
- Native support for package.json and node_modules
- Package management with new deno install, deno add, and deno remove commands
- A stabilized standard library
- Support for private npm registries
- Workspaces and monorepo support
- Long Term Support (LTS) releases
- JSR: a modern registry for sharing JavaScript libraries across runtimes
We are also continually improving many existing Deno features:
- deno fmt can now format HTML, CSS, and YAML
- deno lint now has Node specific rules and quick fixes
- deno test now supports running tests written using node:test
- deno task can now run package.json scripts
- deno doc’s HTML output has improved design and better search
- deno compile now supports code signing and icons on Windows
- deno serve can run HTTP servers across multiple cores, in parallel
- deno init can scaffold now scaffold libraries or servers
- deno jupyter now supports outputting images, graphs, and HTML
- deno bench supports critical sections for more precise measurements
- deno coverage can now output reports in HTML
Deno is a single binary for the TypeScript and JavaScript ecosystems. Deno is secure by default (installing npm libs do not automatically have full system perms/access).
The new standard library stabilizes a vetted collection of safe binaries instead of having to search for and install random libraries for basic or common use cases with [or without] own security assessments.
Deno compile compiles the TS/JS project into a single binary.
The backwards compatibility to npm and npm/js frameworks enables deno usage in existing projects and with existing libs with the benefits of deno and a path to incremental migration.
The announcement video is worth watching. The intro is great.
I think it makes sense that publishers are required to update or at least assess games when open security issues come to their attention.
The current state is that you may have 20 games installed and 10 have not been maintained for a long time, and 5 have open security issues that an attacker may use. For example, a game launcher with service installs to program files with admin permission. And suddenly, you have a privilege escalation.
Or a game, when run, pulls in some monitoring, and suddenly exfiltrates data because that service is defunct and was taken over, or hacked.
The necessity is quite clear.
Maybe this will also push us towards more stable software, that changes less, or has less attack or escalation surface. That could significantly reduce maintenance burden - even if it ends up only assessing reported open vulnerabilities not affecting your product (because you don't make use of or open up the vulnerable functionality).