In this Blog entry I want to share the experiences I made with Github from a (frontend-)developer’s point of view.
Explicitly I want to explain how I
- forked my first project
- submitted a PR (pull-request) to an existing repo
- published an own project on Github & NPM
- got my first issues and PRs
and everything that comes with it.
What happened?
As I started diving more into frontend-development (especially Angular) I came more in touch with npm and its repository. For the Electronic Door Opener we have at work (a self-made solution for opening a door with Apple Homekit) we utilize homebridge, which is a NodeJS server that you can extend with plugins. While playing around with homebridge I installed a plugin that broke the entire NodeJS server. That’s when I started digging out my Github profile to fix that issue.
Forking, fixing, submitting
The solution for getting the broken plugin to work again was very easy (actually it was not a nice solution but oh well…). So what I did is just
- forked the plugin
- cloned the forked repo
- fixed the error
The plugin had a dependency that had a new release. The owner of the dependent project didn’t follow the semantic versioning guidelines, he had breaking changes in the API from version a.b.c to a.b.d. I decided to set the dependency to a fixed version (“^a.b.c” –> “a.b.c” in package.json) instead of reworking the whole (foreign) code. - committed and pushed the changes back to Github
- made a PR to the owner of the original plugin
After a few days (yepp, that’s the downside if you have to rely on others) the owner accepted the PR and I could install the working plugin via npm.
To increase the chances that your PR is accepted at all, I’d recommend to reduce the work for the owner of the repo by also updating the Readme (if applicable) and the version number in the package.json.
My own project and the first stars, followers and issues
The Idea
Looking for plugins, I only found solutions for integrating hardware temperature sensors to homebridge. The accuracy of the Weather App on my phone is enough for me though. So let’s se what we can do.
OpenWeatherMap fitted my needs the best, it has a generous amount of API-calls with a free account and provided quite accurate information also for European locations (in contrast to WeatherUnderground for example).
The programming part
On the basis of an existing homebridge plugin (unfortunately I don’t exactly remember which one it was) it didn’t take long to implement the functionality. The actual code is nothing special, no rocket technology here. It’s basically Javascript that does some XHR-requests to the OpenWeatherMap API. If you want to check out the code, feel free, PRs are welcome.
Publish & Install
Publishing to npm
I was truly surprised how easy this step was. All you need is to sign up for a free account.
In the command-line, switch to the root of your repository and run
|
1 |
npm publish |
It asks you to sign in and if the project-name is available (npmjs.com/package/PROJECTNAME) it is published and immediately available for everybody to install via
|
1 |
npm install -g PROJECTNAME |
That’s all!
The first issue
Wow, that was fast. Less than 100 lines of code in the initial version and npm publish – that’s it. Now my work is done here…
Or not? I came back to Github a few weeks later and found that I had two open issues (Why didn’t I get an email??) already. Not a bad thing, I felt more guilty than angry so I fixed the code as fast as I could and repeated the steps above (commit, push, publish) and closed the issues. Now I’m checking my repos more frequently.
The rest
The plugin has 23 stars and 4 forks on Github by the time of writing. In the last month it was downloaded more than 550 times. People started watching the project and following my Github profile. What a nice community!
And the others?
Yes, I have to admit that I was surprised when I found that 4 persons had already forked my plugin. So I looked what they were doing in their repos. One of the forks had a new functionality (showing humidity) that I found quite interesting. So I also implemented that feature in my repo as well (that’s gonna show him…). Competition is good for business, right?
Final thoughts
The experience of writing and sharing code on Github and make it available for everybody with npm was amazing. I would’ve been writing the code anyway and with a few easy steps lot’s of people can now benefit from it. When you then get the first stars it is really encouraging. I don’t consider issues as a bad thing, to me it is a feedback that my code is actually used. If you publish something and there are no issues, you are either a very good developer or nobody is using the code. Sometimes you don’t even have to maintain the code because people are gonna fork and fix it and eventually send you a PR.
By the way, that’s how it looks like in action
Leave a Reply