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


I start with that one, but if it doesn’t support the API, I go for another package.


I agree with this counterpoint. Especially with no way to privately publish packages, some users/organizations may fork + republish packages with no intent to maintain them. This policy would benefit from some additional package labeling that I saw discussed on GitHub (e.g. labeling a package as ‘unsupported’).


I like the philosophy that Evan is encouraging here as it can result in a clearer and more self-documenting set of packages. In my first major Elm package I went through a process of initially giving it a cute name (Eve) and after feedback and noting Evan’s philosophy, ended up with the more mundane, but clearer elm-vega. In this case the ‘elm’ bit is not redundant in that it is explicitly a bridge between Elm and Vega rather than an alternative implementation of Vega.

I do wonder though if this approach might be storing up problems for the future as community packages proliferate. A group that share the same name but have different authors can be a mixture of forks with major or minor amendments, of alternative approaches and homographs. If I don’t know all authors, do I chose the one with the most recent edit, with the most active history, the most github stars, the oldest? Or do I deeply brows the API and source to make the judgement? Perhaps we need some form of crowd rating or even review repository that doesn’t rely on github?

(I realise none of the above is a consequence of Evan’s naming policy, but I think the problems are related to those that the naming policy is trying to address).


Yes, so such a collection of packages is discouraged from ever being brought in to existence. People will collaborate on mature packages rather that doing their own thing. Also, I’m grateful to the individual who forked and published one of my packages for saying that it was a fork, with a link upstream, at the top of the README.

I want to make a point of just how absurd naming is in some other language communities. “Circe” calls itself a “JSON library for Scala powered by Cats”. Apparently Cats is “a playful shortening of the word category”. Circe is a fork of Argonaut, whose naming rationale I can’t find but “Circe was a goddess of magic in Greek mythology, and had a role in purifying the Argonauts”. To find any of these, you have to prefix your google query with “scala”, essentially co-opting the “elm-whatever” pattern.

Then there’s the matter that Circe’s own documentation prominently provides no fewer than three pronunciations: “SUR-see, or KEER-kee in classical Greek, or CHEER-chay in Ecclesiastical Latin”. Whenever someone new wants to learn about this library, they have to spend precious time and mental capacity learning about this irrelevant detail and not a meaningful reason to use or avoid the library. Weird pronunciation and non-words pose a further barrier developers who are not native English speakers, or communicate through screen readers or sign interpreters. I have literally been in a standup where another developer interrupted to clarify for the interpreter that what some of us pronounced “lean” and others pronounced “line” was in fact the same tool. Said tool is named after a character in an irrelevant short story, that is quoted at the top of the README, daring you to waste an hour of company time.

Utter madness.


Hi. I have a couple of concerns with this policy.

Memorable names

If someone asks me what package they recommend for x in Elm in a conversation (in person or via chat) I have a hard time naming it without having to search for the package in

For me the author name is a very hard to remember distinction e.g.


I know which one we use and like, but I’ll never remember that name without looking it up.

In Ruby, JS, etc I can tell people straighaway as names are usually easy to remember.

Packages using the same module name

If a couple of packages have the same name, is likely that they will try to export the same module name. This is a problem right now For now is difficult to migrate from one lib to another if they happen to use the same module name, as they will conflict.

If there is a way to rename modules in the future this point is irrelevant.


I have mixed feelings about the literal naming policy, and I agree with @Sebastian. It is really nice to be able to search for a package based on its functionality, but it makes it complicated to try and find a specific package. It’s confusing and difficult to find the version of Elm WebGL that is the correct, up-to-date version, winding a path through a deprecated elm-community package, to a specific author’s version of that package, back to the up-to-date elm-community version.

I mean… Elm isn’t called “delightful language for reliable webapps”. That’s its description. It can be handy to have some marketing and presentation.


At first I agreed with your counter-point but then I realized if I saw those 3 packages and assumed they were Forks of the same Library, the first thing I’d do is check each one to see how/if they differed in terms of their API or functionality. Rather than choosing the one with the most clever name.

…which basically just proved Evan’s point :smile:


It’s very common for people’s usernames to be locale specific and not mnemonic; it’s often a name plus an initial, i.e., a random letter, and the names may be hard to read or even unreadable for people from different locales; it also isn’t helped by separators being usually omitted from names. The ‘cutesy’ names that this policy is supposed to replace at least are usually meant to be mnemonic for English speakers, and the examples of “alice/bob/chuck” misrepresent the reality that most usernames are more similar to “zxcvbn”.

The result of this policy is that I don’t remember package names; I either need to look up their names in elm-package.json, or look through multiple similar packages and possibly still be unsure.

Edit: the ‘clever’ names also serve to signal that effort has gone into the package, while a yet another username/elm-X package just blends in with the others, many of which won’t have seen serious effort or maintenance.


Another significant negative aspect of usernames in package names is that usernames are not permanently fixed; usernames can be changed or the user accounts deleted. This naming system is setting Elm up for a leftpad moment. Just recently Go got burned because of this exact same thing, where someone deleted their GitHub account and broke a large number of Go dependencies.

Usernames being part of package names means that Elm package authors are stuck with their username, even though there can be many legitimate reasons to want to change it. Even people’s actual legal names change.

This is all on top of the naming conflicts, since the namespaced names are only used for installation, but importing modules doesn’t use the namespaces. It’s been pointed out already that the literal naming policy makes naming conflicts much more likely.

npm does it right where you can have user- or org-scoped or packages where it makes sense, and there can’t be conflicts.


As a concrete illustration, I can’t remember the actual names of the few elm-graphql alternatives relevant to me. I thought that the one that didn’t support Elm 0.18 but whose design I was interested in had a relatively short and anglophone sounding person name with an initial letter. I won’t single it out here, but turns out it was a compound of an anglophone first and last name, but instead of an initial letter, it was using the first few letters of the first name, and the last name was somewhat uncommon. The result was that the name is worse than not mnemonic; it’s acively confusing, since it looks like a ‘garbled’ version of a more common name. “zxcvbn” at least is somewhat clearly identifiable as random letters.

It doesn’t help that I’m from a non-anglophone culture, so I’m not really ‘wired’ as well for remembering or parsing anglophone names, like remembering whether something is spelled “Mc” or “Mac”, or differentiating similar names, etc. Anglophone names are just one kind of foreign name as well; for example, Central European language names tend to be difficult to spell and read as well.

There are plenty of difficulties with foreign or unusual names just within the context of Western culture, but the problems are multiplied when considering people from non-Western cultures; Asian cultures, for example. Given that most Elm users currently seem to be Western, this naming policy ends up being very Western-centric.

The bottom line is that the names being dismissively referred to as ‘cutesy’ are typically better suited for international audiences and inherently more mnemonic than usernames. Usernames are commonly not even chosen with any personal branding in mind but just for logging into an account, and usernames are often very locale-specific, unlike how package names are typically chosen. For example, the single Elm GraphQL package whose name I’ve had no difficulties to remember has been Graphqelm, and it’s now apparently slated to be renamed to [username]/elm-graphql. A simple word play on Graphql and Elm is an obvious memory aid and doesn’t really depend on a specific cultural background while being fairly literal; meanwhile, the username in question is the opposite in both aspects of mnemonic value and locale specificity.

There’s some aesthetic appeal in all packages being named after a uniform descriptive scheme, and the more creative names can sometimes be too figurative, but this naming policy is very arguably a case of throwing the baby out with the bathwater.


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.


There’s a large middle ground between [random animal name].js and every Elm GraphQL package being named elm-graphql; Graphqelm being an example of a name that is both as descriptive as elm-graphql but also unique and mnemonic. Human language is flexible enough that there are an astronomical number of ways to name any given library in a descriptive way, and a library being called “axios” instead of something like “yet-another-http-client.js” is more a stylistic choice than anything. The idea that npm’s public namespace would be close to running out of viable descriptive names for packages is on its face untrue and based on cherry-picked examples. The ‘obvious’ names being taken is not a significant factor, because there are so many possible alternative lexical combinations.

It’s just a false dichotomy between random package names and an uniform naming scheme. There can be a descriptive naming policy without requiring uniform names.

The stated benefit of usernames is putting the focus on the authors, but that is a moot point, because usernames are not fixed, and treating them as fixed means not learning from the npm leftpad fiasco. Usernames and even user account change; this is a central issue that hasn’t been addressed.

npm isn’t perfect, but it gets it right in the sense that a regular user doesn’t need workarounds like mirroring or committing dependencies to guarantee dependencies not breaking. Larger orgs run their own mirrors, but for most people it’s good enough to rely on npm’s central repo. Ditto for; a central repo with immutable packages is a best practice, while coupling packages to specific users or usernames has prominently failed. A more recent example than leftpad is the GitHub user hosting Go’s go-bindata package being deleted.

If the idea is to optimize Elm’s package system for the scale of npm, leftpad should be an important lesson, but an another more significant problem npm still faces is ‘typosquatting’ by malicious packages. Using usernames as part of the package name significantly amplifies the typosquatting problem, since usernames are often difficult to spell.


The best, most obvious for an Elm GraphQL package is elm-graphql. I agree that there exists a second-best name that is not quite as good, but still descriptive. Also a third-best, and so on. A long tail.

If the naming policy is “come up with a name that is short, descriptive, and has never been used before” then the first person to ever publish an Elm GraphQL package gets elm-graphql and everyone else after that has a harder job - come up with a name that’s still short and descriptive, but which none of the N package authors who came before thought of - and the end result is still a less descriptive name than elm-graphql.

What a thankless, unrewarding job, compared to having it be okay to choose elm-graphql!

To be maximally successful in a naming system like that, you have to be first to publish. (When I realized elm was not taken on npm I told Evan he needed to grab it immediately before someone else took it, even though there was no installer to publish yet.) This very directly rewards work that’s done quickly over work that’s done carefully, which is a really damaging incentive to create for an ecosystem.

Given this, it’s no wonder people throw up their hands and start using animal names! If you can’t win on clarity because others already took the best names, optimize for personal gratification instead. It seems to me that the ineveitable result of a “come up with a short, unique, descriptive name” policy is packages with names that have no relation to what they do. The incentives push package authors toward that outcome.

What happened in npm will happen in Elm unless we take steps (like the “choose obvious names” policy) to avoid it.

The leftpad problem was that an author unpublished a package, breaking everything that depended on it.

What does that have to do with naming?


The leftpad problem was that an author unpublished a package, breaking everything that depended on it.
What does that have to do with naming?

The uniform naming policy relies on usernames forming canonical package names, and the leftpad situation was caused by similarly coupling packages to npm user accounts. The point is that neither usernames or user accounts should be treated as fixed or immutable; users should be able to change both, given that it’s tied to their idenity, but a package manager should also give a guarantee that dependencies will continue working. This guarantee is not possible with Elm’s current package system, and the uniform naming policy is predicated on the current system.

The uniform naming policy exacerbates the problem of lack of dependency guarantees by making it harder to get rid of the username namespaces, and it also exacerbates the other major problem of the current system, which is potential module name conflicts.

One more unaddressed concern is the relation of harder to type usernames and typosquatting by malicious packages. It’s a serious problem at npm’s scale, arguably much more so than undescriptive package names.

The whole discussion whether it’s more valuable to memorize package branding or author branding is a distraction in light of technical problems, but names like elm-graphql aren’t even that descriptive, much less perfect; I mean, some of the libraries with that name are query builders, others are code generators, and the name would also apply to utility libraries with an even more different scope.

You contradict yourself with the example of Elm; there isn’t a perfect but taken descriptive name that the name Elm would have been chosen in lieu of. A lot of projects don’t have obvious names, and a lot of random names are random just for stylistic reasons. It’s a silly just-so story that names like “axios” would be about perfect names being already taken instead of the authors, for instance, thinking that “axios” sounds cool, just like how Elm was ostensibly named.


Sorry, but that’s factually inaccurate.

It was caused by the ability to unpublish packages. That’s it.

Naming policy can’t move the needle on typosquatting. Good solutions give users indicators besides name as to the reliability of the package. (For example, which other packages are using it, download counts, etc.)

elm-graphql seems like a descriptive name for a package that lets you use GrahpQL in Elm!

Yes, and the OP in this thread is Evan’s explanation for why we shouldn’t do that in Elm. :slight_smile:

This is a thread about naming.

If you’d prefer to discuss other things, I’d suggest starting a new thread!


Not sure what’s supposed to be inaccurate; npm allowed one way for users to break depedencies, but Elm currently allows the same way and more. It doesn’t matter how it’s done; a dependency author should not be able to simply break even projects pinned to a specific version. Go uses the same approach as Elm and recently had a prominent example of a user deleting their account, causing widespread breakage, and the username being taken over by a different user, raising obvious security concerns.

Naming policy can’t move the needle on typosquatting.

This is an unsupported assertion; making it easier to have typos makes it easier to typosquat.

elm-graphql seems like a descriptive name for a package that lets you use GrahpQL in Elm!

Not less so than a name like Graphqelm, and less so than a name that actually would describe the different scopes covered by “using”, such as code generation vs. query building vs. utility functions like dumping the schema.

Yes, and the OP in this thread is Evan’s explanation for why we shouldn’t do that in Elm.

The point was that there are other explanations to non-descriptive naming than descriptive names being taken; the latter arguably isn’t even that likely, since perfect or obvious names are a contrived idea.

This is a thread about naming.
If you’d prefer to discuss other things, I’d suggest starting a new thread!

It’s a thread about a naming policy predicated on the current flawed package management system, so the flaws are directly pertinent.


I quoted the inaccurate thing, said what was inaccurate about it, and linked to an article on what actually happened. I don’t know how I could be any clearer, sorry!

Agreed! It is currently possible for this to happen in elm-package today because we don’t have our own dedicated infrastructure yet; we are currently piggybacking off GitHub’s infrastructure, and GitHub allows renaming repos.

If we hosted packages on our own servers, this would no longer be a concern (unlike npm in the left-pad situation, there has never been an elm-package unpublish command) but of course building that infrastructure is a serious undertaking. Elm 0.19 lays some of the foundation for that project.


One thing I like about here, and the reason I prefer it to /r/elm, is that a lot of posters here have user ids that are their real names (well, I assume they are, maybe you all just made up fake names). On /r/elm people tend to use pseudonyms, took me quite a while to work out that Evan was ‘wheatbread’ or something like that.

So you could take this whole literal names concept further and say, publish packages under your real name, and create an identity on here with your real name. Who you literally are.


I’ve never said that leftpad wasn’t caused by unpublishing, and I’ve explained that the pertinent part of the comparison is dependencies not being guaranteed.

There’s a reason why sites like GitHub allow accounts to be deleted and usernames to be changed; it’s because people and their circumstances change, and they should be allowed to control their public identity. It’s not a package repo’s place to tell someone what they should be called. People might get divorced and not want to see their old name, or marry, or transition, or just grow out of a name, or need to hide, etc.


It seems to me there are arguments for both sides of this topic.

People may want to change their GitHub username for various reasons and want their packages to follow, sure, and they are free to do so. If dependencies need to be updated due to a change a package publisher wanted to make, be it the API, the name of it, or its accessibility, are all potential bi-products of relying on open source software in general right?

I think Evan understands that, and has chosen the route of literal naming to take advantage of the benefits he mentioned in his post, and one of the costs of that approach is relying on the stability of the package author.