DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for What's so cool about Fig Autocomplete? πŸ’­
Samina Rahman Purba
Samina Rahman Purba

Posted on

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

Image description

Image description

To install Fig:

brew install fig 
Enter fullscreen mode Exit fullscreen mode

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

Image description

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
Enter fullscreen mode Exit fullscreen mode

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.

Image description

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

Image description

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.

Image description

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.

Top comments (1)

Collapse
 
raibtoffoletto profile image
RaΓ­ B. Toffoletto

Interesting tools! I'll definitely check them up. Thanks for the tip!

Let's Get Wacky


Use any Linode offering to create something unique or silly in the DEV x Linode Hackathon 2022 and win the Wacky Wildcard category

β†’ Join the Hackathon <-