dev.to is open source!

This means that when you get annoyed with it, you can do something about it. When you think it has a bug, you can fix it. When you think its missing a feature, you can add the feature. When you're confused how it works, you can go reference the implementation. When it does something cool, you can go see how they did it.

This is a big deal! With closed source tools, we just suffer the same dumb shit for years! Slack and Jira, I'm talking about you.

Adding a feature

So, I knew there was a youtube tag (link), but I host on Vimeo. I cloned the repo (link). Followed the setup instructions from the Readme, and by referencing the code in the youtube tag, was able to submit a pull request to add a vimeo tag (link).

So, now if you type either of these:

{% vimeo 193110695 %}
{% vimeo https://vimeo.com/193110695 %}

You will see:

You can do this too!

It didn't go perfectly, but I was able to get it done. Here's some high-level takeaways I had:

• Start by skimming the README for the relevant parts about how to get setup. If you don't normally do Ruby, they recommend rbenv, which is a good choice (I used ruby-install, chruby, and chruby-fish). Not sure if you need a fancy JS environment or not (I've got one set up by default). If so, nodenv is the best I've found, it's basically the same as rbenv, but for Node. In particular, they work across shells, you put them in place by setting a few env vars instead of evaluating code (doesn't impact shell startup time), remember to run nodenv rehash after doing a global install.
• The test suite doesn't entirely pass on my local machine, but the tests I was referencing did pass. Per instructions in the README, I ran it like this: $ bin/spring rspec spec/liquid_tags/youtube_tag_spec.rb
• It was pretty slow to start up (I blame this), but I waited it out and it worked.
• I really liked how they were doing environment variables.
• A while back I realized I was very wrong about Spring and I took back all my angry comments about it! Thankfully they use Spring on this app. When you know how to use it, it's worth the confusion it can cause when it goes wonky, because of the pain it saves you in startup time. Basically, it means you just do bin/rails console, bin/rails server, and if you ever change anything in config, or shit seems wonky, you do bin/spring stop
• Instead of figuring out how to login, I just edited one of the articles from the console:
• Be sure to try your feature out. Since the test doesn't run the input through markdown, when I tried it in the console, it behaved differently than in my test (the markdown parser modified the input to the liquid tag). Also, when I read the PR template, they talked about documentation and I realized I hadn't updated the markdown basics page, so I quickly added a commit for that.

I think that's probably the core of it. My PR wasn't perfect (it works around the markdown issue rather than fixing it), but for any given project, there is always more to do, and it accomplished what I wanted: there is now a vimeo tag ❤️.

For first time committers

FWIW, my very first open source commit (link) was only 1 line long. It was a bug fix that took me 8 hours to figure out! I felt super vulnerable, but thankfully the maintainer of Sinatra (Konstantin Haase) was really kind, pointed me in the right direction several times, and got my PR pushed through. Super appreciative of that. Dev.to's code of conduct (link) and history of welcoming behaviour implies they will be similarly good OSS shepherds.