I spent a month trying to rename my own npm package. The answer was always the same: ‘security.’
I built FastMCP, the most popular MCP framework in the JavaScript ecosystem. But the name ‘fastmcp’ clashed with a Python project, so I wanted to rename it to ‘vitemcp.’ I owned the domain, the GitHub org, the Twitter handle, and even the npm package ‘vite-mcp.’ All I needed was to move from ‘vite-mcp’ to ‘vitemcp.’
Support refused. ‘Security reasons.’ No escalation. No human review. Just a wall.
The people who build your platform are treated as liabilities, not partners.
This isn’t a story about one frustrated developer. It’s a symptom of a deeper rot in how centralized package registries treat open-source maintainers. The same platforms that profit from our work—the downloads, the ecosystem growth, the innovation—have designed support systems that punish us with silence.
Think about the logic: I created the project. I control every digital asset tied to it. I want to change its name to avoid confusion. And yet, a faceless algorithm or a low-paid support agent decides that my request is a security risk. The irony is staggering. The security policy that’s supposed to prevent namespace squatting and hijacking is being used to block the exact person who built the namespace’s value.
Security isn’t the problem. Unaccountable decision-making is.
You’ve probably never thought about who owns your package’s name. Until you try to change it. Then you realize: you don’t own it. You’re renting it from a corporate support ticket system that can say ‘no’ without explanation, without appeal, and without any real human being seeing your case.
This is the tension that the Mimeng framework captures so well: the conflict between platform security and developer autonomy. npm wants to protect against malicious actors. But in doing so, it treats every legitimate maintainer as a potential threat. The result is bureaucratic dead ends that stifle the very open-source development that made npm valuable in the first place.
I reached out to HN. I asked for help. I’m still waiting. But the lesson is clear: if you build on a centralized platform, you are at its mercy. Your project’s identity is a permission slip, not a right.
So here’s the uncomfortable truth: the open-source ecosystem is running on trust that platforms don’t return. We give them our code, our communities, our reputations. They give us automated policies and unhelpful support. The next time you install a package, remember that its name could be taken away from its creator by a vague ‘security’ policy—and no one will explain why.
Your package name isn’t yours. It’s a temporary loan from a corporate bureaucracy that doesn’t know you exist.
FAQ
Q: Isn't security important? Why should npm allow arbitrary renaming?
A: Security is critical, but it must be applied with nuance. The author owned the domain, GitHub org, Twitter handle, and the existing npm package. This was a legitimate rename, not a hijack. A policy that blocks the owner without human review is broken—it's security theater, not real protection.
Q: What practical lesson should other open-source maintainers take away?
A: Don't rely on centralized platforms for your project's identity. Secure your name across multiple channels early. If you anticipate a rename, do it before your project gains traction. And always have a backup plan—like a custom domain or a self-hosted registry—in case the platform's bureaucracy becomes a wall.
Q: But maybe npm is right to be cautious? Couldn't a rename enable hijacking?
A: Caution is fine, but a month of dead ends with no escalation shows a system that prioritizes process over people. The risk of a false positive (blocking a legitimate owner) should be weighed against the risk of a hijack. In this case, the false positive caused real harm, while the hijack risk was negligible given the author's ownership of all related assets. A better approach would be a human review process with clear escalation paths.