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

JSR Is Not Another Package Manager

deno.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: JSR Is Not Another Package Manager

#41

Post by chaorace »

eqvinox wrote: post #6

Sure, it's not a "Package Manager" by JavaScript nomenclature, where apparently the package manager refers only to the client side piece. Instead it's apparently a "Package Manager" and a "Package Registry"… which most other environments just call a "package manager". As a non-JavaScript developer, drawing this distinction feels incredibly silly to me…

Well... go ahead and try installing JSR on your local machine. You can't, because JSR is a website. Let's do the inverse and try installing a package from pnpm.io! You can't, because the only thing available for download on that website is pnpm itself.

pnpm lets you download packages to your computer -- a "manager", if you will. JSR gives you a centralized place to find packages at -- a "registry", if you will. We use different words because these two things are not interchangeable and it's not just a JS thing.

Re: JSR Is Not Another Package Manager

#42

Post by jitl »

davexunit wrote: post #40
Philip-J-Fry wrote: post #11

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them. Just take things back to…

Go programs are a nightmare to package for linux distros due to the way they handle dependencies so I would strongly discourage any other language from copying the Go model.

This says more about Linux distros creaky 90s era design than it says about Go’s model.

Re: JSR Is Not Another Package Manager

#43

Post by crabbone »

lifthrasiir wrote: post #28
Philip-J-Fry wrote: post #11

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them. Just take things back to…

The fact that Go eventually introduced the central proxy server highlights one of the biggest issues with this approach though: the vast majority of use cases do prefer centralized systems.

The major advantages of centralized systems in my mind are:

* No need to deal with duplicates (what if two indices provide the same version of a package but with different dependencies?)

* Oversight (the ability of most popular package managers to "side-load" from Git repo / URL / etc. "illegitimate" source has been a bane of my existence for a while). Being accepted into some "central" index means at least some (albeit usually not much...) degree of oversight. Being able to load from anywhere means exposure to spoofing.

Also, unfortunately, lots of package management systems in common use can be "subverted" to be used in a decentralized way. And, if it were up to me, I'd rather not have this ability at all than have to try to defend against negative consequences.

Re: JSR Is Not Another Package Manager

#44

Post by swift »

c-hendricks wrote: post #39
postepowanieadm wrote: post #20

Earlier quoted context omitted.

And has some really odd behaviors like https://github.com/microsoft/TypeScript/issues/17053

Are you saying typescript should parse regular expressions? Turn on `noUncheckedIndexAccess` and it works as you expect (plus forces you to check all the places you're doing unchecked access). https://www.typescriptlang.org/play/?noUncheckedIndexedAcces...

Regular expressions are part of the language, so it's not so unreasonable that TypeScript should parse them and take their semantics into account. Indeed, TypeScript 5.5 will include new support for syntax checking of regular expressions[1], and presumably they'll eventually be able to solve the problem the GP highlighted on top of those foundations.

[1]: https://github.com/microsoft/TypeScript/pull/55600

Re: JSR Is Not Another Package Manager

#45

Post by crabbone »

jitl wrote: post #42
davexunit wrote: post #40

Earlier quoted context omitted.

Go programs are a nightmare to package for linux distros due to the way they handle dependencies so I would strongly discourage any other language from copying the Go model.

This says more about Linux distros creaky 90s era design than it says about Go’s model.

Not really. With all the problems of packaging software for Linux, I'll take that any time over Go.

The whole "spirit" of how Go authors approached every infrastructure task they had was to start as simple as possible and grow as necessary, in small increments. Unfortunately, incrementalism doesn't work in this domain. It's very hard / virtually impossible to go back and undo bad decisions once they become public. Some steps will require sweeping changes all across the board and cannot be performed in one increment.

Go packaging mostly works because of the extra restrictions imposed on themselves by most package authors. But, if you were to stray off the beaten path, you'll discover that the system is unprepared to deal with your case. Go is the opposite of thoughtful and insightful design. It wins at first because its fast and easy to do, and once you are hooked, you will have to work extra hard to deal with the difficult parts yourself.

Re: JSR Is Not Another Package Manager

#46

Post by thenerdhead »

I like how they encourage best practices using a score similar to pub.dev & what npm tried to do years ago. Also the compatibility portion is quite interesting given the evolution of runtimes.

I suppose I don't quite understand the rationale of another registry. But perhaps that is what is needed nowadays with various ecosystems and their chosen defaults. What for example prevents npm from adopting ES modules tomorrow? (Although there are many opinions on CommonJS/ES Modules)

Re: JSR Is Not Another Package Manager

#47

Post by nailer »

> higher scores are awarded to packages that include comprehensive JSDoc documentation on each exported symbol

Nope. I love Ryan Dahl, but code filled with JSdoc comments that needlessly replicate type information already in the code, and mandatory descriptions for every variable (often used as a substitute for proper naming) has a really low signal:noise ratio.

Re: JSR Is Not Another Package Manager

#48

Post by tionis »

crabmusket wrote: post #36
Philip-J-Fry wrote: post #11

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them. Just take things back to…

Deno literally did this[1] in order to be browser-compatible[2], and everybody whinged about it. I happen to love that I can just import an HTTPS URL inside Deno code. It's really nice for playing around with libraries, writing little scripts that pull in dependencies, etc. [1] https://docs.deno.com/runtime/manual/basics/modules/#remote-... [2] https://html.spec.whatwg.org/multipage/webappapis.html#modul...

I love this approach in Deno! I did write some nice scripts using this!

Re: JSR Is Not Another Package Manager

#49

Post by Macha »

wwwigham wrote: post #23
Philip-J-Fry wrote: post #11

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them. Just take things back to…

You can use file:// or git:// versioned dependencies in normal npm `package.json`s today. People just don't , outside some edge cases (local packages, nightly versions) because the centralized registry has upsides for discoverability and maintenance. There's also private registries, where you can setup a .npmrc to pull different namespaces from different registries. But if you want, you can totally be that guy who on…

The same is also true of Python, and once used to be the majority option, which was around the time that the "Python packaging is terrible" impression was starting. Since like 2015, pypi has banned it in hosted packages, but you can do it for private packages all you want.

Re: JSR Is Not Another Package Manager

#50

Post by c-hendricks »

swift wrote: post #44
c-hendricks wrote: post #39

Earlier quoted context omitted.

Are you saying typescript should parse regular expressions? Turn on `noUncheckedIndexAccess` and it works as you expect (plus forces you to check all the places you're doing unchecked access). https://www.typescriptlang.org/play/?noUncheckedIndexedAcces...

Regular expressions are part of the language, so it's not so unreasonable that TypeScript should parse them and take their semantics into account. Indeed, TypeScript 5.5 will include new support for syntax checking of regular expressions[1], and presumably they'll eventually be able to solve the problem the GP highlighted on top of those foundations. [1]: https://github.com/microsoft/TypeScript/pull/55600

That's crazy, in the best way
Post reply on HN