soliciting feedback on some implementation details

[ungoldman]

@paulcpederson @nikolaswise since you've both expressed interest in using this module when it's stabilized, I thought I'd ask your opinion on some implementation details.

Everything on the table of steps in the readme has been implemented except for the following three:

• create repo on github
• travis hook added w/ travisjs
• npm publish

I'm wondering if these are beyond the scope of the repo or not. I think the second and third hinge on the first.

• Should module-init create a repo for you? If so:
  • Should it add the Travis-CI hook for you?
  • Should it run npm publish for you?

If it makes sense for module-init to create the repo, all that requires is getting a token from github, which is fairly trivial with ghauth. You'd only need to authenticate with user & pass through a prompt once, then the token would be stored for future inits. That token could also be used for adding the Travis-CI hook with travisjs (I think).

My thought is that it would be nice if it created the repo and did the hook, but publishing a non-functioning module is too much -- that's pretty much just name squatting.

If it makes sense to create the repo, should that be done automatically or should it be a (y/n) prompt? Same question for travis hook & npm publish.

[ungoldman]

I guess one more set of steps between travisjs hook and npm publish would be git add . && git commit -m "init" && git push origin master and running something like gh-release. Which seems like overkill. I think I answered my own question in regard to the npm publish piece but would still like your opinion on the other two steps.

[paulcpederson]

• It should never npm publish.
• It should optionally create a Travis-CI hook
• It should optionally create a GitHub repo

The reason it should never publish to npm is because I view npm as a place for code that is ready for people to use. I know I am maybe alone in this as large swaths of npm are just 0.0.0 no-readme wastelands, but that is my conviction. I stand by that.

[ungoldman]

@paulcpederson I agree wholeheartedly re: npm. Incidentally,

I agree with your recommendations in general as well. Think I just needed someone else to confirm what the voices in my head have been telling me. Thanks!

[paulcpederson]

@ngoldman it seems that npm agrees with us about empty published modules. From their dispute reolution guide:

"Squatting" on a package name that you plan to use, but aren't actually using. Sorry, I don't care how great the name is, or how perfect a fit it is for the thing that someday might happen. If someone wants to use it today, and you're just taking up space with an empty tarball, you're going to be evicted. Putting empty packages in the registry. Packages must have SOME functionality. It can be silly, but it can't be nothing. (See also: squatting.)

[paulcpederson]

Both squatting and empty modules are actually violations of terms of use.

[nikolaswise]

👍👍👍👍👍👍👍👍👍👍👍

I like the idea of (y/n) prompts on both creating a repo and the travis thing. I also endorse not building tools that clutter up public resources with empty trash.

[ungoldman]

Final question: should the default be yes or no for those create repo and travis hook steps? Like if you just press enter enter enter enter should it create the repo and hook or no?

[nikolaswise]

I think default yes is good.

[ungoldman]

Alright feedback solicited, thanks y'all. Final verdict:

• It should optionally create a GitHub repo (default: yes)
• It should optionally create a Travis-CI hook (default: yes)
• It should never npm publish