#jsr — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #jsr, aggregated by home.social.
-
Reading #Deno v2.8 release notes:
deno pack[...] builds a Deno or JSR project into an npm-publishable tarball. Given adeno.json, runningdeno packproduces a [tgz file] that’s ready fornpm publish.Deno 2.8 drops the
npm:prefix requirement at the CLI:deno addanddeno installnow treat unprefixed names as npm packages by default. [...] JSR packages keep thejsr:prefix.If that's not a eulogy for #JSR, I don't know what is.
-
Reading #Deno v2.8 release notes:
deno pack[...] builds a Deno or JSR project into an npm-publishable tarball. Given adeno.json, runningdeno packproduces a [tgz file] that’s ready fornpm publish.Deno 2.8 drops the
npm:prefix requirement at the CLI:deno addanddeno installnow treat unprefixed names as npm packages by default. [...] JSR packages keep thejsr:prefix.If that's not a eulogy for #JSR, I don't know what is.
-
Reading #Deno v2.8 release notes:
deno pack[...] builds a Deno or JSR project into an npm-publishable tarball. Given adeno.json, runningdeno packproduces a [tgz file] that’s ready fornpm publish.Deno 2.8 drops the
npm:prefix requirement at the CLI:deno addanddeno installnow treat unprefixed names as npm packages by default. [...] JSR packages keep thejsr:prefix.If that's not a eulogy for #JSR, I don't know what is.
-
Reading #Deno v2.8 release notes:
deno pack[...] builds a Deno or JSR project into an npm-publishable tarball. Given adeno.json, runningdeno packproduces a [tgz file] that’s ready fornpm publish.Deno 2.8 drops the
npm:prefix requirement at the CLI:deno addanddeno installnow treat unprefixed names as npm packages by default. [...] JSR packages keep thejsr:prefix.If that's not a eulogy for #JSR, I don't know what is.
-
Reading #Deno v2.8 release notes:
deno pack[...] builds a Deno or JSR project into an npm-publishable tarball. Given adeno.json, runningdeno packproduces a [tgz file] that’s ready fornpm publish.Deno 2.8 drops the
npm:prefix requirement at the CLI:deno addanddeno installnow treat unprefixed names as npm packages by default. [...] JSR packages keep thejsr:prefix.If that's not a eulogy for #JSR, I don't know what is.
-
-
B umge/ts-base là template thư viện TypeScript bắt đầu tích hợp many công cụ: Vitest, Biome, tsdown, CI, JSR, Deno... AngularJS migrated here? Th“对 hỗ trợ amis từ Reddit của @FutureIncrease. [Giải Parlamento] #TypeScript #Vitest #Biome #JSR #Deno #OpenSource #JavaScript
https://www.reddit.com/r/opensource/comments/1p6kyuz/bgubtsbase_starter_ts_library_template_vitest/
-
Every time I try to publish a package to #JSR (JavaScript Registry), it frequently gets stuck in the “processing” state, so I'm seriously considering whether I should stop publishing my TypeScript packages there altogether. 🤔
-
Why is publishing packages to #JSR so slow? A lot of the CI time for the Fedify project is spent waiting for the JSR server to process the packages we've uploaded.
-
*shaking butt*
#brcf #jsr #jsrf #funk #bombrushcyberfunk #music #2Mello #gamemusic
-
*shaking butt*
#brcf #jsr #jsrf #funk #bombrushcyberfunk #music #2Mello #gamemusic
-
*shaking butt*
#brcf #jsr #jsrf #funk #bombrushcyberfunk #music #2Mello #gamemusic
-
*shaking butt*
#brcf #jsr #jsrf #funk #bombrushcyberfunk #music #2Mello #gamemusic
-
Introducing #Upyo!
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!
-
Introducing #Upyo!
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!
-
Introducing #Upyo!
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!
-
Introducing #Upyo!
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!
-
Introducing #Upyo!
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!
-
Jet Set Radio OST: Guitar Vader - Super Brothers
#JetSetRadio #DreamCast #SEGA #JetGrindRadio #JSRF #RetroGames #Gaming #RetroGaming #Music #JSR #JRock #PunkRock #RockMusic #Music #2000s #Y2K #VGM #OST #Soundtrack #GameDev #IndieDev
-
Jet Set Radio OST: Guitar Vader - Super Brothers
#JetSetRadio #DreamCast #SEGA #JetGrindRadio #JSRF #RetroGames #Gaming #RetroGaming #Music #JSR #JRock #PunkRock #RockMusic #Music #2000s #Y2K #VGM #OST #Soundtrack #GameDev #IndieDev
-
Add JSR Packages With pnpm and Yarn, by @lcasdev (@deno_land):
-
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. 😇
-
JSR nows shows download counts! Their team's (non-)handling of the community request for this feature is one of the reasons I'm uninterested in the project, but it's nice to see. And it's exciting to learn tailwind-fluid-font-size has been downloaded from JSR around 6000 times!
-
This week on the pod Kamran and Erik unpack JSR, the new open alternative to the npm registry from the folks at @deno_land. They both published packages and discuss what JSR offers npm doesn't, when to use it, and how it works for both consumers and maintainers.
**#typescript** **#javascript** **#jsr**
-
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
-
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 -
Just put the first package on #JSR: https://jsr.io/@nrfcloud/wait-for-it
It's nice that it removes all the tooling needs when publishing TypeScript libraries on NPM, and you basically only need TS source and a jsr.json to describe it.
Very nice to get atomic packages.
-
Exploring Java's Units of Measurement API (JSR 385)
-
JSR 221: JDBC 4 proposed changes…
-
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
#simplewebauthn #webauthn #passkeys #typescript #javascript #node #deno #npm #jsr
-
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
-
Deno dévoile un packagé manager intégré à Deno lui-même qui gère aussi bien les packages npm que JSR.
Introducing your new JavaScript package manager: Deno
https://deno.com/blog/your-new-js-package-manager -
Deno is a JavaScript package manager with more flexibility:
📦️ npm and JSR
🛠️️ package.json and deno.json
👟️ fast -
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 🥹
#javascript #typescript #deno #node #bun #npm #jsr #javascriptwasamistake
-
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 🥹
#javascript #typescript #deno #node #bun #npm #jsr #javascriptwasamistake
-
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 🥹
#javascript #typescript #deno #node #bun #npm #jsr #javascriptwasamistake
-
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 🥹
#javascript #typescript #deno #node #bun #npm #jsr #javascriptwasamistake
-
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 🥹
#javascript #typescript #deno #node #bun #npm #jsr #javascriptwasamistake
-
I don't want to publish to #NPM because that organization has been shitty for a decade now.
#JSR seems like more of the same.
Why didn't #HTTP based #ESM #packageManagement catch on? #JSR says it's because you can't do #semvar, but I don't see why not; just use file paths ("example.com/package/major/minor/patch/")
I don't see an advantage to publishing #modules to a #package #registry at this time.
-
I don't want to publish to #NPM because that organization has been shitty for a decade now.
#JSR seems like more of the same.
Why didn't #HTTP based #ESM #packageManagement catch on? #JSR says it's because you can't do #semvar, but I don't see why not; just use file paths ("example.com/package/major/minor/patch/")
I don't see an advantage to publishing #modules to a #package #registry at this time.
