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

51–56 of 56 posts

Re: JSR Is Not Another Package Manager

#51

Post by eqvinox »

chrisweekly wrote: post #35
eqvinox wrote: post #27

Earlier quoted context omitted.

There's one primary tool¹ to access these "package registries" (repositories) though, and it's a 1:n relationship with the tool being generally able to use more than one repository. JavaScript seems to be doing n:1 instead with a whole bunch of frontends to npm.js? And the "special" thing about JSR is that it additionally(?) has its own repo? Put differently — the tool is the standard, and you have a choice of repos.…

> "relatively sure" Sorry, but you're flat-out incorrect. See e.g. https://pnpm.io/motivation See also my response to your earlier comment; in the npm ecosystem you can choose your package registry, and your package manager/client, not to mention your target runtime. Coupling any of these distinct concepts is not the norm.

> Sorry, but you're flat-out incorrect.

I was talking about the non-JS world, i.e. tools like aptitude and Ubuntu's GUI package manager.

Re: JSR Is Not Another Package Manager

#52

Post by mbarneyme »

crabmusket wrote: post #38
mort96 wrote: post #18

Earlier quoted context omitted.

Yet it's the best we have at the moment in terms of statically typed JS (other than JSDoc which encodes the type system in comments, which .. has its own issues).

Does JSDoc even have a type checking system? The point of TS is that is actually does something with your declared types. JSDoc is nice... for docs being interpreted by a human. But unless those are used to create red squigglies then it's kind of arbitrary. I've used JSDoc with TS's type syntax and typechecker in JS files. Which is fine - I find it subjectively uglier but I know some prefer it. But it's still TS that…

JSDoc provides the exact same level of type safety as TypeScript, because the TypeScript Language Server/CLI themselves are what does the type checking. Using JSDoc removes the need to transpile your code before executing it. You still want to type-check your code (with a `tsc --noEmit` or similar) in CI, just like you'd run unit tests/a linter/etc.

Re: JSR Is Not Another Package Manager

#53

Post by jitl »

crabbone wrote: post #45
jitl wrote: post #42

Earlier quoted context omitted.

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. So…

I guess I view Debian et al similarly to how you view Go: distros like Debian have been incrementally iterating on a simple design since the 90s and their package systems have become a Katamari Damacy ball of mud around a core designed for having a single agreed-upon version of each C library shared by all software in the universe.

Now to reliably distribute Linux software, it’s very popular to distribute the software along with the entire userspace the software compiled against in the form of a Docker container.

Re: JSR Is Not Another Package Manager

#54

Post by Macha »

eqvinox wrote: post #27
mort96 wrote: post #17

Earlier quoted context omitted.

I mean the exact same distinction is drawn in the Linux space: dpkg/apt and pacman and dnf and opkg are package managers, while Debian's repos and Ubuntu's repos and Arch Linux's repos and Alpine's repos and Fedora's repos and Red Hat's repos are "package registries". It's a natural distinction to draw IMO, even if some tools have a hard-coded "package registry" URL.

There's one primary tool¹ to access these "package registries" (repositories) though, and it's a 1:n relationship with the tool being generally able to use more than one repository. JavaScript seems to be doing n:1 instead with a whole bunch of frontends to npm.js? And the "special" thing about JSR is that it additionally(?) has its own repo? Put differently — the tool is the standard, and you have a choice of repos.…

apt-get, the modern apt command, aptitude...

yum, dnf...

The package registries also have multiple. Sticking with apt repos, Ubuntu has one per release, Debian has one per release, Mint has one per release...

So it's an n:n situation.

Re: JSR Is Not Another Package Manager

#55

Post by crabbone »

jitl wrote: post #53
crabbone wrote: post #45

Earlier quoted context omitted.

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. So…

I guess I view Debian et al similarly to how you view Go: distros like Debian have been incrementally iterating on a simple design since the 90s and their package systems have become a Katamari Damacy ball of mud around a core designed for having a single agreed-upon version of each C library shared by all software in the universe. Now to reliably distribute Linux software, it’s very popular to distribute the softwar…

> it’s very popular to distribute the software along with the entire userspace

OK, there are two ways to interpret the word "popular".

* As in "a presidential candidate enjoyed popular support".

* As in "ski is a popular sport in some European countries".

So, let me tell you this: distributing software with the entire userspace is not popular, if you use the first interpretation of the word. Users hate developers who distribute software like this, this is what they call "bloatware", "not a team-player" etc. I, personally, despise developers who do this, because, from my perspective, these are the low-skill developers who do less to get equal pay at my expense (as a user).

But, of course, it's popular to be a bad developer, in the same way how it's popular to steal bicycles -- low effort, high reward, if you ignore the disappointment of someone else.

Re: JSR Is Not Another Package Manager

#56

Post by crabmusket »

mbarneyme wrote: post #52
crabmusket wrote: post #38

Earlier quoted context omitted.

Does JSDoc even have a type checking system? The point of TS is that is actually does something with your declared types. JSDoc is nice... for docs being interpreted by a human. But unless those are used to create red squigglies then it's kind of arbitrary. I've used JSDoc with TS's type syntax and typechecker in JS files. Which is fine - I find it subjectively uglier but I know some prefer it. But it's still TS that…

JSDoc provides the exact same level of type safety as TypeScript, because the TypeScript Language Server/CLI themselves are what does the type checking. Using JSDoc removes the need to transpile your code before executing it. You still want to type-check your code (with a `tsc --noEmit` or similar) in CI, just like you'd run unit tests/a linter/etc.

Yes, that's my point. JSDoc isn't an alternative to TypeScript if you want your types to actually be checked.
Post reply on HN