DEV Community

Joel Jucá
Joel Jucá

Posted on • Updated on

Introducing .iex.local.exs

I love command-line interfaces! And, I like to customize my CLI experience as well. Either it being one-character-long aliases, utility functions, or just preloading some data into helper variables, my shell is always customized to some extend.

When I'm working with Elixir, I use IEx, which in turn allows you to customize itself through .iex.exs files. I truly love it! However, if I'm working on a team with other developers and they do like to do the same, we'll be in trouble. If this .iex.exs file is being controlled by Git, we'll both have the exact same customizations (and it won't be customizations anymore).

This week I wrote a solution that's so simple I decided to share.

Behold .iex.local.exs!

OK, I'm being a bit extravagant here. 😂 The idea behind this .iex.local.exs file is: any team-wide IEx customization goes on .iex.exs directly (e.g.: customizations that you as a team agreed to use), and anything too personal to be team-wide goes on .iex.local.exs. Then, your .iex.exs file will end with the command below:

# Local dot-iex file (user/environment-specific, Git-ignored)
import_file_if_available(".iex.local.exs")
Enter fullscreen mode Exit fullscreen mode

The file .iex.local.exs should be Git-ignored, so it will be entirely user/environment-specific. There you can create your own aliases, preload/prepopulate utility variables, provide utility functions, etc. You name it!

How about you? What have you been doing/using to be more productive in your work?

Latest comments (0)