chore(deps): Upgrade Elixir to 1.20.4, and upgrade some deps whose old versions are now incompatible.

[joshlarson]

Scope

Asana Ticket: 🛠️ (2026/09) Upgrade Elixir and Erlang

Implementation

Note

🤖 While I did the original Elixir upgrade by hand, I used Copilot to clean up most of the resulting compile-time warnings. As usual, commits with robot in the prefix (e.g. fix(warnings/robot)) were AI-generated. The others were human-generated.

Elixir version 1.20 introduced some nifty new type checking and warnings, some of which we ran afoul of, generating warnings that I wanted to get cleaned up before issuing this PR. Those new type checks were:

• It now warns on unused requires
• It's a lot smarter about type inference now. Many of the commits remove or clean up assertions/refutations that can't fail based on the types.
• Specifically, it's a lot better at detecting unnecessary pattern-matched clauses, sometimes based on patterns specified elsewhere in the code. A bunch of the cleanup commits remove unnecessary pattern-matches that we hadn't removed before now.
• It also is a little too excitable about macros. See live_isolated_component below.

Commits 2-10 of this PR address ☝️ warnings within our codebase that I (well, Copilot) was actually able to clean up.

Commit 11 upgrades ex_cldr_units and ex_cldr_numbers, because those two libraries are run at compile-time, and the old versions had type issues that Elixir 1.20 warned about.

Commits 12 and 13, well... see live_isolated_component section below.

Unnecessary pattern-matched clauses

I wanted to highlight this example because it's pretty cool!

The DotcomWeb.ScheduleController.TripInfo module defines a private current_trip function, which handles empty and non-empty journey lists like so:

  defp current_trip([%Journey{} | _] = times, now) do
    do_current_trip(times, now)
  end

  defp current_trip([], _now), do: nil

However, current_trip is only called in two places (one, and two), both of which explicitly have a pattern-match preventing journeys from being an empty list:

  defp trip_id(...)
       when journeys != [] do
    current_trip(journeys, ...)
  end

So Elixir's new type checker detected that journeys can never be [], and that the empty-list-handling clause of current_trip/2 was unnecessary.

Pretty neat!

live_isolated_component

The flip-side of this is that the new type-checking gets a bit too excited about macros. live_isolated_component itself is defined as a macro, like so:

defmacro live_isolated_component(component, opts) do
  do_live_isolated_component(
    component,
    quote(do: if(is_map(unquote(opts)), do: [assigns: unquote(opts)], else: unquote(opts)))
  )
end

In the tests where we use it, we invoke live_isolated_component like so:

live_isolated_component(SearchResultsLive, create_assigns())

And create_assigns() is known at compile-time to be a %{map}.

So we end up with the macro expanding to something like

  do_live_isolated_component(
    component,
    if(is_map(%{map}), do: [assigns: %{map}], else: %{map}))
  )

And of course %{map} is a map, so we get a warning.

Copilot suggested the hack of wrapping the create_assigns() call in Function.identity/1, so that Elixir would forget what its type was.

(Arguably less important: The reason there are two commits was because I wanted to show the AI's first attempt, which was to wrap each create_assigns() call in Function.identity/1, as well as my proposed cleanup ((also actually implemented by Copilot)) of moving the Function.identity/1 call to the definition of create_assigns/0)

How to test

We should somewhat thoroughly test this out in a deployed environment to make sure that everything still works.