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

91–100 of 183 posts

Re: JSR: The JavaScript Registry

#91

Post by seniorsassycat »

lucacasonato wrote: post #66
m3h wrote: post #64

Earlier quoted context omitted.

Another comment in the thread makes a very good point: > Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes. Add to that the frequent compilation issues that happen as TypeScript adds or removes types in the global imports, cha…

Look at the comment under the comment you mention - those issues are about the TS type system, NOT the TS syntax. TS syntax is highly stable, and is the only thing JSR relies on :)

How is that true if the npm compatibility layer serves compiled js and .d.ts files?

Re: JSR: The JavaScript Registry

#92

Post by m3h »

lucacasonato wrote: post #78
m3h wrote: post #62

As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…

> This sounds like another building service I don't control. There's already too much magic in publishing transpiled TypeScript packages but at least the current tools let me control exactly what artifacts get pushed out. For tools that natively support TypeScript, you can directly consume the TypeScript source code. No transpilation necessary. The complexities are only introduced (well not really introduced, just mo…

Thank you. I stand corrected on some points. The messy ecosystem of npm, yarn, pnpm, JS, TS, ES, and ESM has all cost me a good amount of white hair.

A good source of my confusion came with not immediately recognizing that a new package registry does not require a new package manager to work with. I think the "jsr" commands in the code samples and the jsr.json make it feel like there's a new package manager in play here. If the team has made it so that npm works with "jsr" and vice versa, kudos to them because that's a big win for the users.

Re: JSR: The JavaScript Registry

#93

Post by digging »

pier25 wrote: post #63
imbnwa wrote: post #4

Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.

I'm still surprised by so many projects betting on TS. ES will introduce types at some point and all this effort around TS will again divide the JS community.

Is that a good reason to write in raw JS today?

I'm not betting anything on TypeScript. It was released 11 years ago, and it's incredibly valuable to me. If it takes another 5 years for ES to implement first-class types, and it's a good implementation, I'll start using ES for new work at that time. What's lost here? TS won't just stop compiling.

Re: JSR: The JavaScript Registry

#94

Post by darepublic »

One solution to the package dependency swamp is to make a project with little to no dependencies? I'm rambling but I would curious to experiment with an approach where, when I needed a bit of code to solve a problem the "package manager" (more like code procurer) would just find a snippet of code I need, perhaps reference it's origin, perhaps add related unit tests and then I would copy paste it into my own code base.

Re: JSR: The JavaScript Registry

#95

Post by seniorsassycat »

papa0101 wrote: post #34
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 }

It's not even needed anymore: "HN".padStart(10); That's it.

Does pad start respect RTL marks? /s

Re: JSR: The JavaScript Registry

#96

Post by cumwolf »

darepublic wrote: post #94

One solution to the package dependency swamp is to make a project with little to no dependencies? I'm rambling but I would curious to experiment with an approach where, when I needed a bit of code to solve a problem the "package manager" (more like code procurer) would just find a snippet of code I need, perhaps reference it's origin, perhaps add related unit tests and then I would copy paste it into my own code base…

i think this could function in a small project scenario and i like the idea. Don't think that would be super maintainable in larger enterprise applications. You'd essentially be on the hook for maintaining more code as well.

Re: JSR: The JavaScript Registry

#97

Post by fhd2 »

chaorace wrote: post #79
fhd2 wrote: post #73

Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic…

esm.sh is a decent solution for this. It's not totally ideal... but it'll turn NPM modules into ES6-compatible URLs no problem.

Oooh, esm.sh looks pretty close to what I'm looking for, thanks!

Re: JSR: The JavaScript Registry

#98

Post by fhd2 »

lucacasonato wrote: post #80
fhd2 wrote: post #73

Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic…

> Exposes these libs as proper ES6 modules. We don't do this natively (yet?), but esm.sh supports JSR alreay: https://twitter.com/jexia_/status/1762516242626416750

Thanks for pointing this out!

Re: JSR: The JavaScript Registry

#99

Post by seniorsassycat »

tentacleuno wrote: post #29

This is great! I very much like the added TypeScript support (which the standard NPM registry does not have.) and that it's open-source. I'll see about getting my packages uploaded onto here, too -- just having built-in support for TypeScript makes packaging x100 easier. Regarding NPM, it's absolutely insane that we've been depending upon a closed-source, monolithic nightmare with poor UX for so long. You can't even…

I'm not sure jsr fixes comments in package.json, and I wouldn't blame npm for the miss feature.

package.json is used at runtime by node.js and strictly parsed as json. Npm or just could strip comments on publish, but local development of the package would break.

Not sure if bun or demo use pjson at runtime or if they allow comments.

I think it's interesting that JavaScript projects at the package root despite most projects compiling to dist nowadays. I'd like tool to generate the whole package root, including a transpiled or generated package.json

Post reply on HN