Name

[rtfeldman]

If I were searching the package website for a graphql package and saw these search results...

1. jamesmacaulay/elm-graphql
2. pro100filipp/elm-graphql
3. ghivert/elm-graphql
4. Xerpa/elm-graphql
5. chrisalmeida/graphqelm
6. dillonkearns/graphqelm

...my familiarity with the Elm ecosystem leads me to assume the first 4 are the serious options, and the last 2 are not worth investigating. That's a shame, because you've clearly put a ton of thought into this!

The thing is, I've had one bad experience after another with packages that don't follow Elm's "give it an obvious name" guideline. Cute names seem most often to be chosen because the author is an Elm novice coming from a JS background, where there's one shared global npm namespace instead of a per-author namespace, and "branded libraries" are the norm.

Naturally, packages created by folks who are new to Elm tend to have a lot of room for improvement!

Have you considered calling this dillonkearns/elm-graphql instead? Based on my experience, I suspect that you'd see more experienced Elm users discovering the library and giving it a shot.

[dillonkearns]

Hey Richard, thank you for starting this thread here, this is very much a conversation I would like to have (in fact, I started a similar discussion over on #graphql). I completely agree with this literal naming convention, and I've really appreciated that about the Elm ecosystem.

The main thing stopping me from renaming the package right now is that npm doesn't have the same author-namespacing approach as elm packages, and the elm-graphql npm package name is already taken. As it turns out, jahewson/elm-graphql appears to not be actively maintained anymore. I wonder if the author would be willing to donate it? If I could get that npm package then I would have no reservations about renaming it to dillonkearns/elm-graphql. But since it is taken, I'm a little stuck. It would be confusing for the npm package to have a different name.

I suppose I could name the npm package something like elm-graphql-generator as well, but that seems a bit confusing, especially given that there is an elm-graphql npm package. What route would you take in this situation?

Thanks for chiming in on this, I really appreciate your input!

[rtfeldman]

It looks like elm-graphql-cli is open on npm, for what it’s worth... 😸

[rtfeldman]

If it were me, I'd just go with elm-graphql-cli and mention that in the README.

Separately, I pinged John on meetup.com (he used to go to the SF Elm meetup - great guy!) and I'll let you know if he's open to donating elm-graphql on npm.

[dillonkearns]

That's fantastic, thanks for checking with John! I understand if he doesn't want to give it up for some reason, but I'd be really stoked if he were up for donating it!

I'll wait a few days to hear about the elm-graphql npm package name before kicking off the migration. The sooner the better, but it would be nice to avoid telling people to update their npm packages twice in a row.

[harmboschloo]

Alternatively, you could use @dillonkearns/elm-graphql for npm, but you have to pass the flag --access=public to make the package public. See also http://blog.npmjs.org/post/168978377570/new-package-moniker-rules

[sporto]

Also for consideration:

It is not possible to import two packages with the same root module name elm/compiler#1625

In our case we use two libraries, the one we were using which uses GraphQL and this one, which we are migrating to.

If you were to change the lib to elm-graphql and use GraphQL it will mean that we might not be able to use it. We probably can as they these lib doesn't export exactly the same modules e.g. GraphQL.Client.Http and GraphQL.Http in this one, but it will be very confusing.

[dillonkearns]

This is a great discussion, and your point about memorable names on discourse particularly resonated with me @sporto.

I'm wondering if there's a way to get the best of both worlds and have a name that is both memorable and literal (and perhaps even more descriptive).

How does the name elm-graphql-interop strike you all? Is it confusing, or does it help convey the idea? I have a package called elm-typescript-interop which similarly generates code to extend type-safety beyond Elm and to the interop between Elm and TypeScript. I wonder if the term interop could give the impression of something similar to anyone browsing Elm GraphQL packages? I would love to hear everyone's feedback and ideas!

[mattdb]

The -interop suffix implies a more specific use case to me than the generic elm-graphql. As in, without knowing anything else, I might assume this package is less fully featured, which IMO is not an accurate impression.

I get the desire for something unique, though. And I have experienced the pain of migrating between two identically named packages. All of these pains are real! Without language support for identically named packages / aliasing (or whatever the solution might be), I find the literal naming policy a bit unfortunate.

[martimatix]

I'm not getting a sense of what the package does from interop.

Of the options presented, I like Richard Feldman's suggestion of elm-graphql-cli. That is, I think to myself: "What am I installing? Oh yeah, the CLI part of the elm-graphql library that I'm using." It's also one of the shorter names presented.

[sporto]

I don't think the node module has to be named the same. As long as the names look closely related. You could have the Elm package name plus -cli there.

[dillonkearns]

Thanks for the feedback @mattdb, @martimatix, and @sporto, I really appreciate it! I think you're right about the interop name. I wish there was some nice solution that worked well for all these considerations!

[slikts]

Please don't use a generic name, it makes it hard to tell different packages apart, since user names are not mnemonic. I can remember GraphqElm because its name has to do with GraphQL and Elm; meanwhile, your username might as well be random letters

[lukewestby]

@dillonkearns do you know if you can install an npm binary from a scoped package? something like

npm install -g @dillonkearns/elm-graphql-or-whatever-you-decide-is-best

i also wanted to offer that the name of the cli probably isn't as consequential as the elm package name since folks tend to call the cli from higher level build tools like rake or npm run anyway

[dillonkearns]

@lukewestby yes, from reading through the docs, it looks like the rules for bin files don’t have any special behavior for unscoped packages, so it looks like you can have any name for your bin files that you choose. I don’t imagine that you could name a bin file with a path like that. But I could publish the npm package as @dillonkearns/elm-graphql and from there have it use the binary name elm-graphql, that seems like a pretty good solution!

Good point about the cli being abstracted away in package.json files. As long as the instructions are clear, people will just copy-paste them into their scripts. I like this idea, great suggestions @lukewestby and @harmboschloo 👍

[xtian]

I don't think there is any problem with the current name.

The desire to use "literal" names for all packages seems to be in conflict with several technical realities. Community conventions are great (and I'm not opposed to this one in principle), but conventions only make sense if they are in the context of a coherent technical environment.

As @sporto noted there is a need to facilitate migrating from one package to another. In a non-trivial app, what is the intended way for someone to migrate from @foo/elm-graphql to @bar/elm-graphql?

There is also often a need to wrap a library with application-specific logic. In the app I work on, we have a GraphQl module that wraps this library with logic for building authenticated requests using our credentials type, converting scalars to app-specific types, etc. Given that it is currently an Elm convention to not namespace modules by the name of the application (this is a convention in other ecosystems such as Elixir), the implication is that app code should use a less literal name than library code. That is strange to me.

Based on my experience, I suspect that you'd see more experienced Elm users discovering the library and giving it a shot.

This would be disappointing if true. I think more experienced developers will simply evaluate the project based on how well it helps solve their problems.

[rtfeldman]

@xtian Unless I'm missing something, it seems like you're talking about module names, not package names, yeah?

[xtian]

Typically there is a correspondence between the two, correct?

[rtfeldman]

They're often related, but are still decoupled - and the concerns you brought up apply only to module names.

For example, if two packages happen to expose a GraphQL module, and someone wants to switch from one to the other, that sounds like a motivating use case for elm/compiler#1625 - regardless of what the packages are named!

[rtfeldman]

Given that it is currently an Elm convention to not namespace modules by the name of the application (this is a convention in other ecosystems such as Elixir)

We actually do this at work. For example, we have an Nri.Rollbar module which wraps the generic Rollbar module with some metadata we always like to include that's specific to our application.

I did not know that was a convention in the Elixir community!

[xtian]

For example, if two packages happen to expose a GraphQL module, and someone wants to switch from one to the other, that sounds like a motivating use case for elm/compiler#1625 - regardless of what the packages are named!

Right, but we have to make decisions based on the current situation, not a possible future where we may have different technical constraints.

[xtian]

I did not know that was a convention in the Elixir community!

Yes, for example the controller module in this Phoenix guide is namespaced with HelloWeb. That's the convention for all modules in an Elixir application.

The equivalent in Elm would be if every module in rtfeldman/elm-spa-example was namespaced with ElmSpaExample (e.g., module ElmSpaExample.Page.Article.Editor …). That would prevent any conflicts between app code and third-party modules.

[itsgreggreg]

...my familiarity with the Elm ecosystem leads me to assume the first 4 are the serious options, and the last 2 are not worth investigating. That's a shame, because you've clearly put a ton of thought into this!

That's a strange way of blaming the name of this package for elm package search not having any useful sorting/ranking UI

Based on my experience, I suspect that you'd see more experienced Elm users discovering the library and giving it a shot.

More experienced elm users will read the code/docs because they know the elm package search UI is borderline useless

[rtfeldman]

@itsgreggreg Attacking people (and the work they've done for you, for free) is not the best way to make a feature request. 😕

[dillonkearns]

Thanks everyone who chimed in on this topic, and thanks Richard for opening the issue!

I've made the change now with the Elm 0.19 upgrade:

dillonkearns/elm-graphql Elm package
@dillonkearns/elm-graphql npm package

See the changelog for more details.

[slikts]

I've recommended this library to people in conversations, and every time it just feels stupid to have to say "used to be called graphqelm, but now it's just one of the elm-graphql libraries", since I don't have a good memory for usernames.

[rtfeldman]

@slikts When I recommend it to people I say "elm-graphql by Dillon Kearns." It's quicker to say, plus it explicitly credits the author.

I bet you can remember the author's name if you give it a shot. 🙂

[slikts]

I bet you can remember the author's name if you give it a shot. 🙂

This is really rather condescending. 🙂 My abilities are what they are. They're good enough for mnemonic names like graphqelm, but usernames tend to slip from memory. Even if spent the extra effort to memorize the username, the people I'm talking to wouldn't. As time passes, I'll probably forget the username before the old library name again. My memory won't be refreshed, because I don't use the language, because I don't want to be part of a playground for pet social-engineering ideas like these. It's particularly unseemly to then make issues to pressure others to conform.

[Jayshua]

I'd just like to add that I can never find this library on the first try anymore. It isn't the first result on Google anymore (It doesn't even show up on the first page for me.), nor is it the first result on Github anymore. It is on Elm though, because the results are sorted alphabetically by username.

[sporto]

In a meetup the other day someone mentioned that they were using GraphQL with Elm. I asked which library and they said elm-graphql. I had to ask about the author, that didn't come naturally.

Someone that doesn't know about this policy might have just left with this information and search google later and end up quite confused.

[itsgreggreg]

Packages are often have many contributors. Packages may change ownership between versions. Describing the part of the package name before the / as the "author" is often inaccurate. Asking something like "what is the full name of the package?" Can easily result in confusion as "elm-graphql" is the full name as it is with many other packages.

Essentially this sort of naming scheme doesn't help with either:

1. How do I distinguish elm packages by name?
2. How do I determine the quality of an elm package by its name?

Many communities help with 1 by coming up with memorable, unique names for their packages and trying not to step on each-others' toes. It is not a perfect solution but can help for many things like asking questions, google searches and general conversation. For example, it would be nearly impossible to find the correct information if rather than jquery, prototype, and mootools we had ejohn/js-helpers, sstephenson/js-helpers and kamicane/js-helpers. Not only would information discovery and searching be significantly harder but after a couple of years those names would be inaccurate as big projects are often transferred to organizations and the username would change.

2 is just impossible and I don't really see how anyone can relate purely the name of a package to the quality of it's code. That seems absurd to me.

---

As a side note, we know the package is an elm package, it's written in elm, it's on package.elm-lang.org. Do we really need elm- in front of every package name?

[dillonkearns]

Hello everyone, I welcome this discussion, this is not a constructive place for it though. It will be much more productive and visible somewhere like discourse. If you'd like to discuss further, please open a discourse thread. To make the conversation as constructive and fruitful as possible, I would recommend framing the post(s) as something like "how do we recognize multiple contributors with the Elm community convention of literal naming?" Or "how do we make it easier to recommend libraries at meetups with literal naming?"

For this particular library, I would like to follow whatever the community convention is. I appreciate that we're all trying to make this a better experience, and I know that reasonable people can come to different conclusions about the tradeoffs. Please follow up in a different venue. Thank you!