展示HN：为一种新语言（Coi）设计包命名空间
嘿，HN（黑客新闻），
我正在构建 Coi，这是一种基于组件的语言，可以编译为 WASM、JS、CSS 和 HTML，具有 O(1) 的响应性（没有虚拟 DOM）。
我刚刚发布了一个内置的包管理器，但有趣的部分并不是实现，而是作为包管理器用户我从未考虑过的生态系统设计问题。
我一直在思考的问题是：如何处理命名？像 auth 或 json 这样的全局名称似乎没问题，直到有人抢注它们。
先到先得的方式会产生扭曲的激励机制。声誉系统在早期容易被操控。
我在这个问题上反复思考，时间比我愿意承认的要长。
我尝试了几种方法：
- **黑名单常用名称**：保留像 auth、json、http 这样的名称，以迫使人们使用更具体的名称。
理论上感觉很干净，但谁来决定这个名单？而且这并不真正可扩展，总会有人找到下一个你没想到要阻止的通用名称。
- **Go 的方法**：直接使用 GitHub URL 作为包标识符。不需要注册表，也没有命名战争。
我喜欢这种优雅，但在实际操作中，写和读都很糟糕。
没有人想在源文件中写 import github.com/someone/thing/v2/pkg/util。
- **分级命名**：短名称很难获得，长名称是开放的。声明 json 需要审核，但 json-schema-validator 可以自由获取。
摩擦与名称的价值成正比，没有人会抢注 my-very-specific-http-retry-client，因为没有收益。
我喜欢这个方法，但你仍然需要定义阈值，然后你又回到了需要治理的问题 :( 只是一个更小的版本。
- **作用域名称**：最终我选择了这个方案。一切都是 @someorg/http-client。
乏味、经过验证，避免了抢注而不需要我没有的治理基础设施。npm 通过艰难的方式解决了这个问题，所以我不必再经历了 :)
注册表本身是基于 GitHub 的，元数据是 JSON，提交是 PR，验证通过 CI 进行。
现在注册表中只有一个包（我的），但让 add/install/upgrade 端到端工作改变了项目的感觉。
它从“编译器实验”变成了一个具有实际生态系统形态的东西。
我很好奇其他人是如何思考这个问题的，特别是在早期阶段的生态系统中，你还没有声誉信号。
有没有人比“只使用作用域”更好地解决了命名问题？
Coi: [https://github.com/io-eric/coi](https://github.com/io-eric/coi)
查看原文
Hey HN,
I'm building Coi, a component-based language that compiles to WASM, JS, CSS and HTML with O(1) reactivity (no virtual DOM).<p>I just shipped a built-in package manager, but the interesting part wasn't the implementation,
it was all the ecosystem design questions I'd never thought about as a user of package managers.<p>The problem I kept circling: how do you handle naming? Global names like auth or json seem fine until someone squats them.
First-come-first-served creates perverse incentives. Reputation systems are easy to game early on.
I went back and forth for longer than I'd like to admit.<p>I went through a few approaches:<p>Blocklist common names: reserve things like auth, json, http so people are forced into more specific names.
Feels clean in theory, but who decides the list? And it doesn't really scale, someone will always find
the next generic name you didn't think to block.<p>Go's approach: just use GitHub URLs directly as the package identifier. No registry needed, no naming wars.
I liked the elegance of it, but in practice it's awful to actually write and read.
Nobody wants import github.com/someone/thing/v2/pkg/util in their source files.<p>Tiered names: short names are hard to get, long names are open. Claiming json requires vetting,
but json-schema-validator you can grab freely. The friction is proportional to how valuable the name is,
nobody squats my-very-specific-http-retry-client because there's no payoff.
I liked this one, but you still need to define the threshold and then
you're back to needing governance :( just a smaller version of it.<p>Scoped names: ended up here. Everything is @someorg/http-client. Boring, proven, sidesteps squatting without
needing governance infrastructure I don't have. npm figured this out the hard way so I don't have to :)<p>The registry itself is GitHub-based, metadata is JSON, submissions are PRs, validation runs through CI.
Only one package in the registry right now (mine), but getting add/install/upgrade working end-to-end changed how the project feels.
It went from "compiler experiment" to something with an actual ecosystem shape.<p>Curious how others have thought about this, especially early-stage ecosystems where you have
no reputation signals yet. Did anyone solve the naming problem better than "just use scopes"?<p>Coi: <a href="https://github.com/io-eric/coi" rel="nofollow">https://github.com/io-eric/coi</a>