Release 0.4 for Thimble Mozilla

This is the last blog post of the “Contributing to Thimble Mozilla” series. Watch me embark on the epic quest for the “Solution” while continue bugging David Humphrey  for reviews of my code. I will also attempt to link my narration with some useful tips on how to start Open Sourcing (from my personal experience, so don’t expect them to be complete).

In my previous post, I fought the problem of incompatible styling of my code and the upstream. It quickly escalated into a huge PR with around 140 comments. Eventually, I resorted to defining custom linting rules for my file. Obviously, the rules didn’t make it into the resulting code because defining multiple sets of rules for different files is plain bad idea.

Having said all of the above, it got me thinking of how to robustly validate all of the incoming code, so contributors and reviewers could focus on what really matters – writing great code. My initial though was to put all my local rules into the .eslintrc.json file. This will allow any code to be validated before it is committed. Now, I understand that it was a silly thing to do, expecting a huge project like Brackets to accept my humble rules. So I expressed my concern to David Humphrey and he pointed me to the issue where he had already started the same conversation (probably after reviewing my previous PR). There, a lot of big-shot developers were arguing about how to solve the problem. I tried expressing my humble opinion on the topic and gently proposing myself as the person to go for implementation. Obviously, nobody payed any attention to me, thought it was expected. My real goal here was to merely make them aware of my presence, so they would eventually go to me for the implementation.

The discussion seized after consolidating on using Prettier for code formatting. A week of nagging David about this problem (and my previous comment in the issue, hopefully) led to me being assigned to this issue.

To anyone who is staring their contribution path to Open Source, I would say: “Don’t be afraid to be a little too persistent and ask express your thoughts in places where you are obviously over your head. It is the only way people will acknowledge you.” Make sure that you are saying something sensible, though.=)

I like to think that starting my code from a wrong perspective is just my style of programming. This case is no exception. I started by watching the video on Prettier suggested in the issue’s comments. It wasn’t really helpful, so I turned to my good old buddy Google for suggestions. He was really helpful in providing me with the full documentation, not really what I was looking for, but at least I gained some solid ground. Next, I had to fight a wild boar – the Grunt. It was another technology that I had no idea of how to use, so it took some more time exploring its API and different extensions. Eventually, I landed on the grunt-exec, which is command line extension for grunt. Lucky for me, Brackets code was already using grunt-exec; unlucky, it was my first step in the wrong direction.

I blissfully started tweaking Gruntfile.js to call Prettier through grunt-exec in one of the tasks. As usual, I would be glad to show you the snippet, but I have dropped the commit…

Here is my second advice: “Never drop your commits. If anything, just squash them into one and leave it there.”

In any case, my attempt was only a partial success, but partial is not good enough. On one hand, I did manage to run Prettier from console, on the other, there is a list of directories that I needed to avoid formatting; that list is defined as follows:

gruntfile_meta

The exclamation sign before the pathname indicates the directories to be avoided. The problem is, I could not make it work with bash globbing. A couple of days went by and I referred to David for advice.

My third suggestion to you: “Never be shy to ask questions. Most of the time, other people in Open Source are delighted to answer your questions. However, before asking anything, be ready to answer incoming questions about the nature of your problem”.

Back to me. After consulting with David, I was pointed in a new direction. It turns out, that there are Prettier extension for Eslint: eslint-plugin-prettier and eslint-config-prettier.

At this point I should have know that there is some sort of plugin or extension for everything.

Both of the extensions require a specific version of Eslint installed. The problem is, Brackets does not directly use Eslint, instead it relies on grunt-eslint to get the job done. So I needed to update grunt-eslint to the latest version to make it compatible with eslint plugins.

The last challenge was to decide when exactly to format the code. For now, we’ve settled on updating on every commit. This was achieved with the help of grunt-githooks. Its intent is to create a bash script that would be executed before every commit. In my case, it will runs a grunt task.

githooks_snippet_2

And here is the task itself (The full file could be viewed here):

grunt_snippet

This is it! Now every commit is preceded with the grunt task that formats all of the code and adds it to the current commit.

As you can see, it was a long and winding road that led me to the solution, so my last advice here is : “Don’t be afraid to get into a tight corner, this experience will enable to identify the correct solution.”

Here is my pull request.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s