4 ms·

A guide to publishing JavaScript open source projects

6 points by benmanbs 12y ago

benmanbs 12y ago
Author here to address any questions or corrections
lhorie 12y ago
A couple of other things I do w/ Mithril.js ( http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/ ) - write documentation for the API methods (and arguments, return values, and arguments to callbacks and their return values, if applicable) and show examples of usage - follow semantic versioning (x.x.X for bug fixes, x.X.x for backwards-compatible changes, X.x.x for breaking changes) - consider versioning documentation in addition to releases if your project can be used as mission critical software (e.g. if it's a framework). This can be as simple as creating a task that copies a snapshot of the docs to an archive - maintain a change log - make sure your release is on the master branch (not gh-pages) if you're publishing to component.github.io - setup channels of communication for discussion and support (gitter.im, IRC, mailing list, etc) - create a tag in StackOverflow.com
- benmanbs 12y ago
  Thanks so much for the read! There were some things I intentionally left out (how to write good code, documentation) because I figured those were out of scope of this post (I did try to reference them subtly with the line "the code is in a place where it’s ready to publish"). I also left out some of the things you mentioned (versioning documentation, changelog, channels of communication, SO tag) because I figured those might fall into a Part 2 type of post, where I'd say "Now that you have a first version of your library published, let's discuss how to maintain it." I'll be honest with you, I had a little issue with the length of this post, so I was trying to balance how much to include or omit. I really appreciate the feedback, and I'll keep those points in mind for a Part 2 post!
  - lhorie 12y ago
    It was a good post, I wasn't trying to criticize it, just wanted to add to it based on my own experience :) Looking forward to a part 2!

6 points by benmanbs 12y ago

Author here to address any questions or corrections

A couple of other things I do w/ Mithril.js ( http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/ ) - write documentation for the API methods (and arguments, return values, and arguments to callbacks and their return values, if applicable) and show examples of usage - follow semantic versioning (x.x.X for bug fixes, x.X.x for backwards-compatible changes, X.x.x for breaking changes) - consider versioning documentation in addition to releases if your project can be used as mission critical software (e.g. if it's a framework). This can be as simple as creating a task that copies a snapshot of the docs to an archive - maintain a change log - make sure your release is on the master branch (not gh-pages) if you're publishing to component.github.io - setup channels of communication for discussion and support (gitter.im, IRC, mailing list, etc) - create a tag in StackOverflow.com

benmanbs 12y ago
Thanks so much for the read! There were some things I intentionally left out (how to write good code, documentation) because I figured those were out of scope of this post (I did try to reference them subtly with the line "the code is in a place where it’s ready to publish"). I also left out some of the things you mentioned (versioning documentation, changelog, channels of communication, SO tag) because I figured those might fall into a Part 2 type of post, where I'd say "Now that you have a first version of your library published, let's discuss how to maintain it." I'll be honest with you, I had a little issue with the length of this post, so I was trying to balance how much to include or omit. I really appreciate the feedback, and I'll keep those points in mind for a Part 2 post!
- lhorie 12y ago
  It was a good post, I wasn't trying to criticize it, just wanted to add to it based on my own experience :) Looking forward to a part 2!