#jsr
I'm definitely having fun hacking away at #silverbullet. 
Right now, getting used to using the #javascript import. Which can effectively pull almost any js module. And with #jsr being a thing... let's just say silverbullet instance is going to get weird. 
I'm honestly surprised it took this log to learn of this gem. Likely due to my still very much liking #logseq. Although... give me a few weeks... I'll likely build my own journaling system on this thing. 
Resonac Holdings is studying deal structures for a possible acquisition of government-owned chip linchpin JSR. https://www.japantimes.co.jp/business/2025/02/19/companies/resonac-chipmaker-acquisition/?utm_medium=Social&utm_source=mastodon #business #companies #resonac #jsr #jic #chipmakers #acquisitions #ai
https://jsr.io/@lil5/stupidwebauthn-client
I released my #npm package in #jsr during a jsr presentation at #fosdem2025
Really easy to implement!
The OpenAI JavaScript SDK is now on JSR 
️
#Development #Guides
Everything I know about Deno · A deep dive into the Node.js alternative https://ilo.im/161qe5
_____
#Deno #Runtime #JavaScript #TypeScript #JSR #API #OpenSource #WebDev #Backend #Server
Exploring Java's Units of Measurement API (JSR 385)
Heya TypeScript + WebAuthn fans, I just published v13 of SimpleWebAuthn! This one includes (opinionated) registration hints support, improved support for attestation trust anchors, and a surprise retirement of the types library (for baking-in the types instead into both the browser and server libraries.) Check out the release notes for more info!
https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v13.0.0
As a side note it's simply incredible how Deno has evolved since its debut in 2018. I was able to replace huge swathes of dependencies while working on v12.0.0 thanks to Deno's built-in functionality, including monorepo management, unit testing, linting, and formatting.
And JSR as a package registry stands to save many library maintainers like myself a lot of time. This is thanks to not needing to juggle a build step before publishing. Write in TypeScript, publish as-is, and let the registry negotiate building your code for both ESM JavaScript and TypeScript projects at install time. The fact that it lets you install packages in both Node and Deno projects is icing on the cake.
It's a good time to be an open source JS/TS library maintainer 
It took nearly three weeks of refactor and getting more comfortable with how Deno works, but I'm happy to announce that SimpleWebAuthn v12.0.0 is now also available to install from JSR
https://jsr.io/@simplewebauthn
Check out the CHANGELOG for more info:
https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v12.0.0
Hey, anyone wanna take this out for a spin and report back? It's just some types so nothing too fancy, but it's my first package published to JSR.io 
First it was cool to target just Node, even if TypeScript added some complexity to the bundling process! Worth it!
But then there arrived Deno, which was TypeScript-first and came with a ton of tools built in...but required rewriting to stop using Node-specific data types, to include extensions on every relative import across the entire code base, then finding and referencing deps by HTTPS addresses, and then finding and incorporating another build process for two of the three monorepo packages to maintain the ability to deploy to NPM. Okay, fine I guess...
But wait! Announcing "Web API runtimes" like Bun and Cloudflare workers, and Vercel, requiring test harnesses to try and test future releases in.
It's cool, though: everything still fetches packages from NPM!
Except now there's deno.land/x that can host packages for Deno?! Fine, I'll support that too for the packages that make sense to run server-side.
Except wait there are Deno frameworks with SSR support that can load browser packages from deno.land/x too! But my third, browser-centric package not rewritten for Deno is now suffering from its lack of Deno support!
Maybe rewriting these packages to deploy through JSR.io might eliminate the TypeScript build step, support Node, Deno, and everything else, and make this browser package available in Deno projects?
Well Deno 2.0 did just drop, with workspaces support to boot, so if I'm going to do this, do I also refactor my monorepo to use Deno's workspaces support instead of this working combination of pnpm and Lerna and NX? Except the VS Code Deno extension's "format on save" breaks when you enables workspaces...
...Oh, don't mind me. Just some reminiscing from the OSS maintainer trenches 
std/cli, tools for building interactive command line tools, is now stabilized at v1 on JSR
Deno is known for its HTTP imports, but we've found it's insufficient for larger projects. This post explains the situation and how we've improved it.
Is there any way to track adoption of packages hosted on JSR.io?
As a library maintainer I currently deploy builds to NPM and Deno X package hosts. While the thought of moving everything over to JSR is very appealing (a single place to publish code to), I want to see people are moving to JSR before I invest in it as a third package host, before slowly deprecating the NPM and Deno X packages for just JSR instead.
Something else that's bugged me about JSR is until npm install gets first-class support for JSR it feels weird to ask people to run npx jsr ... install. That pulls down a copy of the JSR library from NPM any time they'd want to install my packages...
std/crypto, extensions and utilities to the Web Crypto API, is now stabilized at v1.0.0 on JSR
