Builtin module names not prefixed?

[xbwwj]

For examples, std and rust in

import * as std from "std";
import { cargoBuild } from "rust";

It seems that instead of the naked module names, the scoped naming pattern is more preferred in modern JavaScript runtimes, like node:fs for Node.js, npm: and jsr: for Deno, and bun:sqlite for Bun.js, while unscoped name are only used for user defined packages, like import maps and package.json.

The nix package manager also uses a similar pattern like github:NixOS/nixpkgs for their official packages.

The unscoped names may also look inconsistent if brioche allows remote modules in the future (like http: and git+https:, as proposed in #333). It may also bring conflicts if brioche introduces package.json like mechanisms.

[kylewlacy]

So, some background context: we're most like Nixpkgs in this case. There aren't any built-in modules (well, not user-facing anyway!), std and rust are both from brioche-packages. Also, we do have support for "explicit dependencies"-- like a package.json basically. When you do an import like import "std" without specifying it explicitly, we treat it as if you had a dependency of "std": "*" (the version gets locked in the lockfile still). Either way, names are resolved from the reigstry or from the current workspace.

(Just wanted to provide some information about how things work today just so we're on the same page!)

---

Early on, I definitely considered using a prefix like brioche:std, etc. I don't feel super strongly about either direction, but some random thoughts:

• I don't think conflicts here will be an issue. I think name, prefix:name, and schema://url should all be unambiguous for parsing. So really it comes down to which style we prefer to go with!
• Prefixes would especially make a lot of sense for custom registries. (today, custom registries replace the default registry, and are "all or nothing". I think it'd make more sense to have something like import "yourcompany:somepackage", where yourcompany is the name of a custom registry you configured)
• I do kind of like Docker / Docker Hub's approach, where the top-level scope (unprefixed) has the most common images and is managed by Docker themselves, but under that, users can manage their own scope with whatever names they want.
• Personally, I do slightly prefer being able to write import "std" over import "brioche:std". 99% of the time, I want an import from Brioche Packages! Unlike Node.js / NPM / JSR / Deno / Bun, Brioche + Brioche Packages are under one roof, so we don't have to worry about ecosystem fragmentation (and if it does become something we need to worry about, it'll be a far future problem)
• ...but, for my CLI change ideas, requiring a prefix could actually help make things more consistent. That would mean that brioche run thing could always run thing in the current dir (equivalent to brioche run ./thing), while brioche run brioche:thing could always run thing from the registry

So currently, I'm still mostly leaning towards using unprefixed names like today... but I do think it'd be a good idea to support prefixed names as well. Which is to say, we could handle it similar to Node.js, where we support both import "std" as well as import "brioche:std" (plus custom prefixes for custom registries). In our case, it would be unambiguous though, since brioche: would always be the "default" prefix ^{(except when the name is resolved from the registry)}.

But definitely want to hear which direction others would prefer! I'm definitely not opposed to switching to prefixes if that's what most folks want

[xbwwj]

Will Brioche support multiple versions of brioche-packages?

For example, in my NixOS configuration, I use nixpkgs stable branch for stability, while picking several packages from unstable branch to get cutting-edge features and fixes.

How can this kind of multiple versioning of brioche-packages be disambiguated in Brioche without prefix? Or does Brioche work like rolling releases like Arch Linux, which only have latest packages?

[kylewlacy]

Today, we only support fetching the latest version of each package, so it's effectively rolling-release. We do store all previous versions of packages though, and they'll be fetched if they're pinned in a lockfile.

We also have an open issue to build multiple versions of a package within the same project (#97). That'll be used for, say, LTS versions. That'll let you install node@22 and node@24, and both will be "current versions". Once one version is no longer supported upstream, we'll stop building/publishing it as a "current version".

Finally, the registry indexes packages by the specific version. I think eventually you'll be able to install, say, node@24.0.0 and get that exact version (assuming we built it before node@24.0.1 was released). But I haven't really thought through how this feature should work, or if we should support installing exact versions like this...