consider renaming module to something descriptive

[mykmelez]

We should consider renaming the module to something descriptive, like offline-gh-pages, per these best practices for naming Node modules.

On the other hand, command-line utilities benefit from being short and sweet, and Oghliner exposes a command-line interface, in addition to its module interface. So perhaps it makes sense to keep the existing, compact name.

[wfwalker]

my first three suggestions:

• sw-publish, to emphasize publishing and service workers
• gh-publish, to emphasize github and publishing
• ghp, to emphasize github and publishing

[mykmelez]

The word "publish" is attractive and accurate. I originally used it when starting development of the project. But I changed to "deploy" because it appears to be the more conventional term, especially when describing the process for web apps ("publish" may be a bit more common for web sites).

To wit: Travis CI's motto is "Test and deploy your code with confidence." And they feature "deployment" to a variety of hosting providers, including GitHub Releases (although not GitHub Pages, which is why this project's configure feature is useful).

[mykmelez]

Oghliner avoids describing Service Workers in its documentation because it intends to make them an implementation detail. Although I don't expect it'll support AppCache (like Surge does) or another offlining API, it still shouldn't be necessary to know what a Service Worker is in order to offline your app and deploy it to GitHub Pages. So I'm loathe to change the name to something that references service workers.

[mykmelez]

sw-publish, to emphasize publishing and service workers
gh-publish, to emphasize github and publishing
ghp, to emphasize github and publishing

These names have a strong "publish" bias, and they suggest that this project's value proposition is to deploy to GitHub Pages.

It's true that this project is carefully scoped, and that Node modules often follow the Unix philosophy, per https://github.com/mattdesl/module-best-practices#module-basics, to be "small programs that do one thing, do it well, and compose easily with other programs."

Nevertheless, this project's value proposition is actually that certain developers would benefit from a tool that composes a set of those "small programs" in a particular way to address a specific use case: deploying offline web apps to GitHub Pages.

If a developer only wants to offline their app, then this project is not the right tool, since such a developer would be better served by a module like sw-precache that helps them accomplish that specific task (with configuration options for deployment targets other than GitHub Pages).

Conversely, if a developer only wants to deploy their app to GitHub Pages, then this project is similarly overkill, as they can integrate a module like gh-pages into their workflow for that purpose (although it's true that such a developer would still benefit from using this project to configure Travis auto-deploy).

So "offlining" is just as essential a feature as "deployment" to the project, and it would be misleading to emphasize only the latter in its name.

[delapuente]

I like oghliner because it is a pun between off and GitHub. Isn't it? So it emphasizes the two core concepts of the project, deploying in GitHub and offlining an application.

I think it's me who must change the name of offliner to something emphasizing the life cycle for an application concept, let's say, cyclapp (I like the idea of an eye —a circle— depicting the life cycle) and thus, oghliner will be using cyclapp to fulfil its purpose. So, if you agree, let's rename offliner instead.

[mykmelez]

I like oghliner because it is a pun between off and GitHub. Isn't it? So it emphasizes the two core concepts of the project, deploying in GitHub and offlining an application.

Yes, it's that pun! Which I figured was clever. But clever names are not always a great idea. When I was involved in naming projects for Mozilla Labs, clever names generally seemed like a good idea at the beginning of a project's lifecycle, because they were catchy and clever, but a bad idea further down the road, because they required an act of memorization to remember. Over time, I grew to appreciate descriptive project names, which both name and summarize the project.

These module best practices suggest naming conventions that "generally favour clear and 'boring' names." I suspect the author is suggesting descriptive names.

[mykmelez]

I think it's me who must change the name of offliner to something emphasizing the life cycle for an application concept, let's say, cyclapp (I like the idea of an eye —a circle— depicting the life cycle) and thus, oghliner will be using cyclapp to fulfil its purpose. So, if you agree, let's rename offliner instead.

It may indeed be worthwhile to change the name of offliner, but note that this issue is not about distinguishing between this project and offliner, it's about choosing the best name for this project! Even if you rename offliner, it might still make sense to rename this project, giving it a descriptive name.

[delapuente]

You're right, thinking about but I continue liking oghliner or offliner for this project.

[mykmelez]

npm-check-updates provides the ncu command-line tool, which leads me to consider renaming this to offline-github-pages and providing an oghp command-line tool.

[mykmelez]

Also of note: despite the advice in that "best practices" document, popular npm packages aren't all descriptively named. Many are, like change-case, github-slug, read-yaml, and travis-encrypt; but there are plenty of others with figurative/idiomatic names, like chalk, gulp, mocha, and nock.

[mykmelez]

After thinking about it for a while, and implementing it in #184, I've decided that we shouldn't rename the project after all, because it's better to keep the names of the npm package and CLI tool the same; it's easier to talk about a project with a single word name; and the downsides of a figurative name aren't significant enough to override those benefits.