The Exercism Elixir track is a test harness as much as it is a set of exercises

Ninety three exercises, each with a reference solution

The repository is the Elixir track for Exercism, linked from the track page at exercism.org/tracks/elixir. The exercises directory holds the practice problems, and the README's test output shows the shape of the suite: it begins at accumulate and acronym, both marked Pass, and ends at zipper, with a total line reading 93/93 tests passed.

The number matters because it tells you what running the whole suite costs. The README says plainly that this will take some time, which is an unusual thing for a documentation file to admit, and it is the reason the script accepts a list of exercise names. Testing two exercises instead of ninety three takes seconds:

$ ./bin/test_exercises.sh word-count zebra-puzzle
Testing: word-count Pass
Testing: zebra-puzzle Pass
--------------------------------------------------------------------------------
2/2 tests passed.

The full run prints the same per exercise lines and a summary, so the output is greppable and you can see exactly which exercise failed rather than only that something did.

The repository is not just the problems either. Alongside exercises/ there is a concepts/ directory, a reference/ directory, docs/, a config/ directory, and .appends/, which suggests per exercise appendices to the shared concept pages. The mix.exs and mix.lock files at the root confirm this is a Mix project, and mix.lock is what pins the dependency versions for the whole track.

The bin/ scripts are the real interface for contributors

Most of the README is about running checks, and those checks live in bin/. The pattern is the same for each one: a shell script you execute from the repository root, which the project also runs for you in CI.

There is a script for the full exercise suite, bin/test_exercises.sh, one for Dialyzer, bin/dialyzer_check.sh, one for formatting, bin/check_formatting.sh, and one that fetches the track tooling, bin/fetch-configlet. That last one is worth understanding, because configlet is the piece that is not specific to Elixir.

configlet is described as an Exercism-wide tool for working with tracks, and the README tells you to download it by running the fetch script. Once it is present you run its lint command to verify that all exercises have all the necessary files and that the config files are correct.

That lint step is what keeps a track with many exercises honest. A new exercise that is missing a metadata file, or a slug that breaks the naming convention, is caught by configlet rather than by a human reading a pull request. The README shows a failing case where the exercises.practice.slug value is transpose with an emoji in it, which the linter reports as not being a lowercase and kebab-case string, and it points to the Exercism documentation on resolving such problems.

Dialyzer and formatting run in CI, so style is not a review argument

The Dialyzer script is the slowest part of the local workflow. The README states that running bin/dialyzer_check.sh on all exercises might take a really long time the first time you run it, which is the familiar cost of building and caching a PLT before the first analysis. It is also run for you by GitHub Actions as part of the pull request check.

That last point is the design decision worth noting. The repository decides that type level errors and formatting are not things a reviewer should be arguing about in a diff, so both are enforced by automation on every pull request. The formatting check, bin/check_formatting.sh, covers all exercises and all documents, and it too is run by GitHub Actions as part of the pull request check.

The formatting tooling is visible in the top level entries. There is a .formatter.exs, which is the Elixir formatter configuration, and a .prettierrc with a .prettierignore, which covers the non-Elixir documents. The presence of both tells you the track keeps its prose and its code formatted with different tools, and checks both.

There is also a .dialyzer_ignore.exs at the root, which is where type warnings that the project has decided to accept are listed. That file is the honest counterpart to running Dialyzer everywhere: some warnings are known and recorded rather than fixed.

Version ranges decide whether your local setup can run the track

The setup section is short and has one hard constraint in it. The exercises currently target Elixir versions from 1.16 to 1.20 and Erlang/OTP versions from 26 to 29, and the README points at the Elixir installation page for detailed instructions.

For version management it recommends the asdf version manager, specifically to manage multiple Elixir versions. That recommendation makes sense for a track that must build against a range of Elixir releases rather than a single pinned one, and it also hints at a practical difficulty: an exercise that passes on 1.20 may not pass on 1.16, and a contributor working across the range needs more than one interpreter.

The repository also targets a specific dependency set through mix.lock, and the .formatter.exs and .dialyzer_ignore.exs files are read against the Elixir version in use. Running the scripts on a version outside the stated range is not something the README describes, so treat the range as the supported configuration rather than a suggestion.

One naming detail catches the eye in the contributing links. The README points to HELLO.md and CONTRIBUTING.md on the master branch of the repository, while the default branch of the repository itself is main. The links still work because the files are present at the top level, and both files are listed among the repository entries along with CODE_OF_CONDUCT.md.

Contributing has two separate entry points

The contributing section splits into two audiences. If you want to help maintain the Elixir track, the README points to HELLO.md, which contains an introduction to all the possible ways you can help. That is the track-level guide, the place for the work that is not specific to one exercise, such as concept material or track policy.

If you want to contribute to this repository specifically, the README points to CONTRIBUTING.md. The distinction matters for anyone opening a pull request, because the two documents cover different scopes and the specific one is the one that describes the checks you will be asked to pass.

The README also states a recommendation that is worth reading as a workflow rule: it is recommended to test before submitting a pull request. The stated reasons are that it will test your submission, ensure the repository builds as a whole, and help guard against unintentional, unrelated changes. That third reason is the one people skip. An exercise change that quietly breaks a different exercise is exactly the kind of regression the ninety three test run is designed to catch, and the partial run with named exercises is a fast pre-check, not a substitute for the whole suite.

The repository also carries a LICENSE file, and the licence recorded for the project is MIT, so the exercise text, the reference solutions and the tooling can be reused in a classroom or a course without copyleft conditions. That is a licensing note rather than legal advice.

A track repository is infrastructure for a community, not a library

The honest limit of this repository is that it is not a library and not a course. The exercises are small, self contained problems, and each ships with an example solution, which means the repository already contains answers to everything in it. That makes it a reference and a test fixture rather than something you would depend on in an application.

It is also not a documentation site. The concept material lives in concepts/ and reference/, with .appends/ holding per exercise additions, and the reader experience is driven by the track page on the Exercism site rather than by these files. If you want the learning experience, you use the site; if you want the exercises and the checks, you clone the repository.

The alternative to writing your own exercises and your own CI for them is precisely the configlet plus script arrangement used here, and configlet is Exercism-wide, so any track you contribute to uses the same tool. A team that wants exercises with example solutions, automated example-solution tests, a type check and a format check already has the pattern to copy from the bin/ directory.

The maintenance picture is narrow but current. The last push was on 2026-10-02, the repository is not archived, the repository topics include community-contributions-accepted and maintained, and the repository has no GitHub releases, so there is no tagged version to pin. The track lives on the main branch and its history is the release record.

Editorial conclusion

Adopt this repository if you want the Elixir practice exercises with a maintained example solution per problem, or if you want to see how a track keeps ninety plus exercises, their documentation and their config files consistent in CI. Do not adopt it as a learning library, since the exercises are deliberately small and come with their solutions. Verify first that your local Elixir falls between 1.16 and 1.20 and your Erlang/OTP between 26 and 29, and note that the full exercise suite is slow enough that the README warns it will take some time, while the Dialyzer pass is warned to take a really long time on a first run.

Frequently asked questions

Official sources

1. exercism/elixir on GitHub
2. Issues
3. License: MIT
4. Project website
5. README