Literal Names Policy (i.e. how to name packages)

In the npm ecosystem, my observation is that:

  • There’s a huge preference for non-scoped package names, and a land grab for obvious ones. Whether or not this is by design, it’s what happens in practice.
  • Popular packages end up with names that have no relation to what they do - e.g. axios (HTTP), jest (testing), aphrodite (CSS).
  • These names must be memorized by everyone who wants to have a conversation about the ecosystem.

I would rather memorize “Dillon’s elm-graphql” than “Giraffe.js” for several reasons - one of the most important being that I’m learning something about a person, a community member, and not an arbitrarily chosen package identifier.

This is especially true for names I’m not used to seeing. The names Tereza, Abadi, and Ilias were not already known to me before I encountered them in the Elm community, and seeing their names in conversations about packages they’ve made helped me learn them.

I get that for non-anglophones, English names are harder to remember than familiar names. But given that both the Elm way and the npm way inevitably require memorization, I think it’s more worthwhile to learn the names (or usernames - I totally understand wanting to decouple legal name from username) of the people in our community than the arbitrarily-chosen names of branded packages.

9 Likes