What's so cool about Fig Autocomplete? 💭

The Perfect Trio ³

It was around 2:00 am when two of my classmates (Batu, TD) and I were online sharing our screens and helping each other out with an open-source project. We were scanning the documentation as we kept working, cautiously coding away to maintain proper style and clean code. We each picked an issue to work on and reviewed each other's codes at the end to squash any bugs ahead of time before making the pull requests.

The three of us decided to work on Fig - a tool that provides IDE-style autocomplete but for the terminal. As developers, we all know how important the terminal is. We thought this would be a cool project to contribute to since we use this tool daily.

What's So Cool About Fig Autocomplete ❓📺

As written in their README:

Fig makes the command line easier for individuals and more collaborative for teams.
Our most popular product is Autocomplete. As you type, Fig pops up subcommands, options,
and contextually relevant arguments in your existing terminal.

Look how beautifully it gives suggestions

To install Fig:

brew install fig 

I use Fig every day. The Fig autocomplete repo had clear documentation and a lot of activity going on. Plus, it was written in Typescript, a language I have experience with. The development environment setup took only a few minutes, again, thanks to the clear documentation. I scanned the list of issues and found an interesting one.

Issue: hyperfine missing spec

What's Hyperfine❓ 🤖

Hyperfine is a command line benchmarking tool with the following features as written in their README.md

Features

• Statistical analysis across multiple runs.
• Support for arbitrary shell commands.
• Constant feedback about the benchmark progress and current estimates.
• Warmup runs can be executed before the actual benchmark.
• Cache-clearing commands can be set up before each timing run.
• Statistical outlier detection to detect interference from other programs and caching effects.
• Export results to various formats: CSV, JSON, Markdown, AsciiDoc.
• Parameterized benchmarks (e.g. vary the number of threads).
• Cross-platform

To install hyperfine I did:

brew install hyperfine

So let's say I type hyperfine ls. This shows how much time it takes the ls command to run on my computer. Below, you see the screenshot of the command run on a 2020 Intel MacBook 13-inch 2020 model with 16 GB RAM.

And this one was done on my 16GB 2021 M1 iMac.

Honestly, this was fun for me to watch the performance metrics. I then followed the documentation and played around with a few other commands across all my machines.

What Are Completion Specs❓ 📝

For this issue, I had to write a completion spec for hyperfine. Completion specs are:

A completion spec is a declarative schema that specifies the subcommands, options, and args for a CLI tool. Fig uses these schemas to generate suggestions.

As mentioned in the issue above, the hyperfine completion spec was missing. I had to read through the documentation very carefully and study the manual of hyperfine to figure out how to get this working.

After typing in man hyperfine on my terminal to pull up the hyperfine manual, I studied the long list of options and commands for the type of arguments I had to pass in. Then, I started coding.
The file ended up being almost 300 lines long, but here is a small snippet of the code structure.

As I was doing the autocompletion spec, I was testing the commands as well to make sure they were working as intended. I also had two more pairs of eyes checking and testing my work before I made the pull request.

Measuring My Progress 📏

This was a much bigger pull request in an open-source project compared to the ones I had done before. I realized that previously I spent way too much time just setting up the development environment and it took time away from the actual coding part itself. I was also working with unfamiliar languages so the scope and size of my contribution were small. This time I decided to work on a bigger repo and write more lines of code.

So, what are some of the things I did right this time, compared to Hacktoberfest which was my very first plunge into the world of open-source development?

1) I read the CONTRIBUTING.md file and followed it.
2) I used proper commit messages as they specified as their guideline.
3) I used proper naming conventions.
4) I looked through their examples of completion specs to make them consistent with others.
5) I squashed and rebased my commits.
6) I was more professional in my communication while making the pull request.
7) I collaborated with others working on this repo so that we can speed up the process and help each other out.
8) I did a lot more research on the topics - in this case, hyperfine and completion specs, before writing code.

Note: I received some feedback from the maintainers to make some minor changes and I am currently working on fixing them.

Well, it is quite evident that as a beginner I learned a LOT of things contributing to open-source projects and I continue to learn something new each day.