Post

Zoltan Kochan
@kochan.io

I am wondering if we should always use some custom protocols like "kahuna:" when the registry is not the public npm registry. So package.json would get something like this:

0 reposts3 likes

Ruy Adorno
@ruyadorno.com

iirc the main motivation to implement it the same as aliases is that's something that can be backported to npm so that we can get to a future where the custom protocol syntax is common across all package managers. Please correct me if I'm wrong @isaacs.bsky.social

Ruy Adorno
@ruyadorno.com

we have much more flexibility given that we haven't reached 1.0 yet but I think the major blocker for the cross-compat is what the npm client can potentially adopt.

Wes
@notwes.bsky.social

I believe I gave this feedback at one point, but also I just want to re-iterate it, I don't think this is the end all for preventing package shadowing issues. As soon as these go one layer deep into transitives it pushes the configuration complexity into every app.

isaacs
@isaacs.bsky.social

Yeah, it's not the end-all for anything (nothing is, that's why stuff keeps not ending, I guess). But having `<known-alias>:...` be sugar for `registry:<url>#...` is very convenient implementation-wise. Transitives are handled by resolving a node's deps by default against the registry it came from

Wes
@notwes.bsky.social

I mentioned it in the other part of this thread, but the better approach is coupling the registry to the client and keeping this sort of configuration at the registry. Ideally running a sidecar caching registry *on every client* which loads up a shared config.

Zoltan Kochan
@kochan.io

I was thinking about just simple named protocols... if you are interested, we can come up with something that will be supported by pnpm and yarn