JSR Is Not Another Package Manager
deno.com
deno.com
Read as: "We wish to uphold NPM tradition of not allowing the authors of code to sign their own code, but as an alternative we will increase your package trust score if you build your package with a heavily censored, centralized, and proprietary build system owned by Microsoft"
How is it that STILL the only source for signed javascript packages are Debian apt-get repos. NPM and JSR still have dramatically worse JS supply chain security than a -terrible- 30yo package manager which still requires a lot of custom tooling overhead in every project for reproducible builds (docker, apt package hash pinning, apt-archive, etc).
Oh right, because the NPM team was worried even having -optional- support for package signing would scare off people from publishing javascript packages.
Just take things back to basics. You shouldn't have to publish a package on some centralised registry, you should just be able to import a package from anywhere.
1. define dependency like bazel_dep(name = "protobuf", version = "3.19.0") 2. define repositories where to look for it
A repository is just a file structure like /modules/$MODULE/$VERSION + some info about the module. Can be on a HTTP server or just on your local file system.
https://bazel.build/external/overview#bzlmod
I hope more tools adopt something similar. Or maybe a single package manager for everything, so we can finally build cross-language software without having to debug why tool A can't find stuff from B.
> Bzlmod discovers dependencies by requesting their information from Bazel registries: databases of Bazel modules. Currently, Bzlmod only supports index registries — local directories or static HTTP servers following a specific format.
It just uses the Bazel Central Registry (BCR) by default. You can specify your own via the --registry flag and then it uses them instead. It is possible to specify multiple registries at the same time, so you can mix the official, company internal and on your local filesystem at the same time.
* 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.
[1] https://docs.deno.com/runtime/manual/basics/modules/#remote-...
[2] https://html.spec.whatwg.org/multipage/webappapis.html#modul...
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.
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.
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.
The Java world got burned by this a few years ago when JFrog shut down Bintray, which had been the second largest open source package repository after Maven Central. A ton of stuff had to be republished, a ton of build configs updated. Now Maven Central is hopefully Too Big To Fail and Sonatype is a sustainable independent business, partly due to the widespread practice of companies buying its Nexus product to mirror Central internally, something I haven't seen so much of in the JS space, and partly because the Java ecosystem doesn't tend to host giant binaries off it. But still.
Gotta admit, I'd like to see a more decentralized approach become popular here. There's no specific reason packages always have to be hosted in one or two central registries.
That is what ESM is. Each https link are basically decentralised registries.
The ECMAScript standard doesn't specify the "ModuleSpecifier" further than a string, so how the module specifier is interpreted and loaded may range anywhere from "a handful of well-known modules" to "any retrievable URI".
Serverless functions, right? That's what deno deploy is billed as. Presumably the registry is a platform-adjacent investment to try and bring more serverless market-share to deno. Since it provides a npm-registry compatible facade, presumably you should feel safe publishing deno-y code to it (without calling platform APIs?), and should thus be more likely to use deno, and thus enter the funnel for deno deploy.
Personally, I just use deno's rust v8 wrappers a bunch, since they make embedding a V8 runtime into a rust app very simple, and js is a very nice scripting engine (especially with optional types). A hugely valuable contribution to the open source community. But then again, I don't deploy serverless functions on the regular. To each their own.
That, together with the fact that you can still host the deno runtime on your own hardware actually makes it a pretty viable alternative to new projects that you would be building using NodeJS otherwise, with the added bonus that if you ever decide to go serverless, you don‘t have to rewrite your code since you can take the same codebase and move it to deno deploy (or supabase functions, which just uses deno under the hood itself)
I also remember thinking it‘s the first and only thing I‘ve ever seen where using the blockchain as the technical basis for it makes sense and isn‘t tacked on for grfiting purposes.
I think this video[0] answers that question, overall I think the video is interesting if you have time to watch it entirely.
Decentralized approach mostly matters for having a curated repo of what teams are actually allowed to use on their projects, instead of having legal surprised by random devs downloading the Internet into their projects.
As anyone that has tried to publish hybrid packages that include types, a CJS and an ESM version, all the while maintaining semver and anything else can be a real hassle. Everyone seems to have a different solution, and most of the time you end up writing a convoluted build system for your package consisting of an amalgamation of tsc, esbuild, rollup or whatever other bundler is the hot new stuff.
As a non-JavaScript developer, drawing this distinction feels incredibly silly to me…
Put differently — the tool is the standard, and you have a choice of repos. In JS it's the other way around?
I would describe the JS situation as… hmm… "oddly tilted" in comparison to other ecosystems; the closest thing I can think of is Python's package management situation?
[¹] I'm not counting GUI frontends here, since I'm relatively sure they just call into the same tool.
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.
I was talking about the non-JS world, i.e. tools like aptitude and Ubuntu's GUI package manager.
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.
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.
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)
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's doing the actual work of determining if all my annotations are compatible when the rubber hits the road.
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...
On a surface level, they have automatic mechanisms for everything that my projects already have implemented, except it has arbitrary limitations, and not a whole lot of material explaining them properly
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.
Call it Genet.