Developers are no strangers to using open source code, it's something normal. As a beginner, it's natural to think that the people behind it have years of experience doing so, I certainly did. If you asked me last week I wouldn't never imagined that I would make my first successful PR. But hey, here we are.
The motive
My journey began a few days ago when I wanted to learn the gist of JSON Web Tokens for user authentication, but didn't felt like messing with an existing project. So I decided to set up a quick server using Express with Typescript, after all, this practice was meant for one and one purpose only (Oh boy, I was wrong).
Problems arised when I decided that I needed Browser Hot Reload, and since I wanted to do Vanilla FrontEnd, I wouldn't set up a tool like webpack. So I decided to go with a lightweight solution, the node-liverload package, it gets the job done, but since it isn't as popular as a dedicated bundler I couldn't find a .d.ts file anywhere, as a result, the TS Compiler wasn't very happy about it.
The determination
After Googling for a bit, I found the usual way to solve the problem, create a local directory to store custom declaration files for existing npm packages. To be honest, that solution would have been enough for my use case, since livereload normal usage requires only 2 lines of code in the app.js file. However, I have been playing with TS for a bit, so it was natural to wonder Wouldn't be nice to have an npm install @types/livereload? (little spoiler, it's available now).
I thought that maybe I would want to use livereload with TS again in the future, and it wouldn't be practical to redo the declaration file, or maybe I was getting ambitious with TS and wanted the full intellisense on the methods. Whatever the case was, I must admit that I was inspired by this article about the process of contribuiting to DefinitelyTyped. It can't be that difficult, right? (For once, I was right here).
The process
Specifically for adding a type for Definitely Typed, the task needed pretty much these steps:
- Write the required file.
- Test.
- Make sure you follow the guidelines.
- Open the Pull Request.
Write the required file.
This part is pretty interesting, I feel pretty much like a beginner in the whole WebDev ecosystem, I had never worked before on someone else's code, as a result, at first it felt pretty daunting What if I'm not ready?, well you got to start somewhere.
In order to make useful Type Definitions, I had to dive in livereload source code, which is written in CoffeeScript (I haven't had the pleasure to learn it neither), therefore, I spent some quality time re-writting it in TypeScript in order to make the appropiate parameters and such.
During this quality time, I learned 3 very importante things:
- How the library works (pretty interesting stuff, to be honest)
- The importance of writing good, clean code (I'm very grateful to the author)
- Coding anything is like building Legos, with the difference that the pieces are huge, and more often than not, you find yourself within a very big community (More on this later).
Test your files
Definitely Typed (DT) (and most if not all open source repos), has a solid guideline in order to make the repo mantainable. One of the principles to make a Pull Request, is to write the appropiate test files and pass them with their configuration.
Specifically in this case, the test is a file that uses the interface/type that you worked on, the suggested way to do this, is to adapt the original library example code to TS, if the compiler finds no problems with it, then you are good to go. I want to notice, that DT have a specific linter for their packages, so some things that would normally run without issues with TSC, don't work here.
As a solo-developer for the last year, I could see that tests may seem something that we could overlook, however, if someone where to modify one file to add functionality, tests are an amazing way to verify if a bug or some breaking changes where made, in order to fix them. In this case, tests where required, but I have seen a lot of pull requests being delayed in order to request tests.
Make sure you follow the guidelines
The main point of this part, is that you will definitely need to address all the guidelines of the specific project you want to work on, that's normal, and it may seem daunting at first, however, stricter requirements usually have very clear instructions.
In DT, the packages must have a tsconfig.json, a tslint.json with the appropiate configuration, otherwise, the PR's aren't merged. Luckily, a tool is given to help with this part.
Open the Pull Request
This is possibly the most nerve-wracking part, I can't exactly pinpoint why. Maybe is the feeling of exposing your code to the world to see, as an aspiring Full Stack Developer, I'm used to show what my code can do, not what my code is, it could be the feeling that I am a rookie who it's about to be judged by the pros.
Whatever it is, I also became more and more excited while this was happening. My first reviewer was a bot, it automates a lot of parts of the process and makes the merging process even more seamless (Definitely Typed contains definitions for about 6000+ packages, it's natural to have a bot there).
Before I realized, the PR tests passed, and a mantainer gave my package the green flag, so, in a couple of hours I received this notification:
Yay, I did it!
What I learned
Never it's to early to give open source a try, this is a small contribution, but I believe that it could help a fellow developer (maybe myself) in the near future. After all, open source is about little building blocks to make great things.
Now I have the confidence to dive in other people source codes, they won't eat me. This kind of collaboration is a great experience that I definitely recommend and expect to live again in the near future.
Consider following me on Twitter, I try to share a little bit of my coding adventure there.
Top comments (0)