JSR: The JavaScript Registry • Hacker News Board

Re: JSR: The JavaScript Registry

#181

Post by antifa » Mon, Mar 04, 2024, 2:00 PM UTC

warpech wrote: post #43

kwhinnery wrote: post #3

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

I am not a user of Deno, but I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM. Was it revised at some point that a package repository is needed? What's the back story?

> I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM

I am imagine most Deno users considered this a weird wart or foot gun, the rest of deno looks interesting.

Re: JSR: The JavaScript Registry

#182

Post by lucacasonato » Mon, Mar 04, 2024, 2:57 PM UTC

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…

CORRECTION:

An employee of GitHub has reached out to me to inform me that there are more than 2 engineers people working on npm full time, including multiple full time support staff and full time staff to review possible malware. The engineering team working on npm is "substantially larger than 2". Additionally they informed me that a new product manager for npm will be starting tomorrow.

Even though I made no claim to the contrary, I would like to emphasise that there are obviously current product managers at GitHub that product manage npm as _one of_ the projects they manage.

Re: JSR: The JavaScript Registry

#183

Post by tentacleuno » Tue, Mar 05, 2024, 3:09 PM UTC

seniorsassycat wrote: post #99

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 pr…

> package.json is used at runtime by node.js and strictly parsed as json

It still constitutes an unfriendly developer experience -- people have had to make workarounds to document what complicated scripts do, and why they use certain dependencies, etc. I understand how JSON.parse works, but this still isn't the best behaviour.

Note that this is just one example of unfriendly UX in NPM as a whole -- this isn't the hill I'm dying on, so to speak, I'm just giving an example of how I believe the industry is being held back by tools which just haven't kept up with demand.