Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSR: The JavaScript Registry

jsr.io

Post reply on HN
Print view View original

11–20 of 183 posts

Re: JSR: The JavaScript Registry

#11

Post by lloydatkinson »

kwhinnery wrote: post #3

Kevin from the Deno team here - happy to answer any questions you have today!

I’m curious what this means in regards to this existing “use Deno to also publish to npm” workflow (https://deno.com/blog/dnt-oak) which I was considering using, and then the JSR announcement happened.

The thing I like about the blog post and the mentioned dnt tool is it takes care of lots of bullshit you otherwise need to figure out when publishing to npm.

What is the relationship between JSR and DNT in this case? Should one be used over the other? Together?

If I want to publish a module so it’s available for Deno and NPM, what is the recommended approach now?

Re: JSR: The JavaScript Registry

#15

Post by winrid »

vdfs wrote: post #13
dazhbog wrote: post #12

Glad the pinnacle of programming is still there: left-pad

The entire source code: export function leftPad(str, len, ch) { return new Array(len - str.length).fill(ch || ch === 0 ? ch : ' ').join('') + str }

that actually seems really inefficient, it could avoid the array allocation and fill call by just moving the length check...

Re: JSR: The JavaScript Registry

#16

Post by kwhinnery »

lloydatkinson wrote: post #11
kwhinnery wrote: post #3

Kevin from the Deno team here - happy to answer any questions you have today!

I’m curious what this means in regards to this existing “use Deno to also publish to npm” workflow ( https://deno.com/blog/dnt-oak ) which I was considering using, and then the JSR announcement happened. The thing I like about the blog post and the mentioned dnt tool is it takes care of lots of bullshit you otherwise need to figure out when publishing to npm. What is the relationship between JSR and DNT in this case?…

As JSR develops, you can expect to see more features like those of dnt start to show up in the npm compatibility layer. We've also been exploring how to create a good DX around simultaneously publishing JSR modules to npm, so publishers can control their namespace there as well. We definitely know it's a usage pattern folks are interested in.

In the immediate term, dnt is still a very strong choice for people that want to develop modules in TypeScript using Deno, and then publish them to npm. In the fullness of time, I expect that JSR will provide a pretty complete solution to this problem as well.

Re: JSR: The JavaScript Registry

#17

Post by lucacasonato »

winrid wrote: post #15
vdfs wrote: post #13

Earlier quoted context omitted.

The entire source code: export function leftPad(str, len, ch) { return new Array(len - str.length).fill(ch || ch === 0 ? ch : ' ').join('') + str }

that actually seems really inefficient, it could avoid the array allocation and fill call by just moving the length check...

You could also just use `String.prototype.padStart()` [1], and you get a nice optimized C++ implementation :D

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: JSR: The JavaScript Registry

#18

Post by grose »

What's the best way to include a binary blob (wasm binary) in your package? For NPM I've been using a bundler (esbuild's `binary` loader) but I'm not sure of the best way to do that in a modern, jsr-friendly way.

Re: JSR: The JavaScript Registry

#20

Post by alex_suzuki »

grose wrote: post #18

What's the best way to include a binary blob (wasm binary) in your package? For NPM I've been using a bundler (esbuild's `binary` loader) but I'm not sure of the best way to do that in a modern, jsr-friendly way.

If you‘re using emscripten, check out the SINGLE_FILE option, that embeds the WASM as a base64-encoded string into the JS.
Post reply on HN