Comments (11)
my first three suggestions:
sw-publish
, to emphasize publishing and service workersgh-publish
, to emphasize github and publishingghp
, to emphasize github and publishing
from oghliner.
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).
from oghliner.
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.
from oghliner.
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.
from oghliner.
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.
from oghliner.
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.
from oghliner.
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.
from oghliner.
You're right, thinking about but I continue liking oghliner or offliner for this project.
from oghliner.
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.
from oghliner.
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.
from oghliner.
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.
from oghliner.
Related Issues (20)
- Update travis-encrypt to version 2
- Oghliner service worker is not deleting out of date offline caches HOT 1
- Tests intermittently fail
- For each `index.html`, cache its parent directory too HOT 1
- Use arrow functions in the service worker HOT 1
- Make Service Worker tests to run on Travis HOT 2
- Provide integration tests for the service worker
- Rewrite some of the testOffline.js tests HOT 3
- Provide a site-root option to allow the offline manager to be included at any page HOT 2
- Setup code coverage for service worker tests
- Assert that prepareCache returns a cache HOT 1
- Consider taking into account imported scripts via `importScript` to generate cache name HOT 1
- Make the update event smarter by avoiding re-fetching non changed files
- Display update notifications for global CLI using update-notifier
- templatze or customize the "a newer version of this page is availalbe" message in offline-manager.js
- oghliner offline ./dist/ doesn't strip dist/ from paths of offlined files
- oghliner.deploy is a footgun HOT 3
- "CLI interface, oghliner as a template/tool" live tests failing HOT 1
- test-sw fails with 'Cannot load browser "Chrome"!'
- switch to using the "deploy" step with a "script" provider
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oghliner.