Verified routes feature is pathological in terms of compile-connected cycles.

[a3kov]

Any module using verified routes creates compile-time dependency on the router. Unfortunately this is pathological in terms of creating compile-connected cycles if you are using verified routes heavily in your project - it is very easy to arrive at a situation where a big chunk of your project is compile-connected.
One way to solve this would be a kill switch that developers would use to enable the checks and to create the compile-time dependency on the router only in certain mix environments. This way we would be able to postpone the checks for CI & production releases - your CI certainly does not care about cycles (as long as it can be compiled). Receiving late feedback on a broken link is not perfect, but we would still be able to catch the error.
Unfortunately the whole feature was not designed with dependency cycles in mind - it even suggests to refer to the router using a module attribute, which automatically creates compile-time dependency on the router too. So even to provide the said kill switch is not so easy. I think this feature needs a major redesign with this issue in mind.

[a3kov]

I would like to elaborate.
"Verified routes" feature provides 2 benefits:

1. Prevents shipping broken links to production. I think everybody would agree that it's a must-have feature.
2. Provides instant feedback to the developer when an invalid path is used

For [1] compile-time check is not the only solution. There are other options:

• pre-commit hooks with static analysis
• mix tasks with static analysis
  .. and probably others.

The option suggested by me would probably be the easiest to implement and can be built on top of existing code - when the killswitch is off (in production or other environments) everything would work the same way, and when it's on all verified routes would automatically become unverified. It would also require minimal changes from users. But deprecating referring to routers in module attributes may be a good idea.

Regarding [2], it is supposed to increase developer productivity, but I would argue due to inevitable cycles in big projects this feature actually kills productivity, leading to many hours lost fighting the cycles. Now, I'm not saying that Phoenix is solely responsible for cycle issues, but it definitely adds fuel to the fire.

[benonymus]

After upgrading to elixir 1.19 we noticed a large cycle in our _web part of our application seemingly as a direct result of verified routes. With elixir 1.18 this cycle was not showing up.

[SteffenDE]

@benonymus if I read this right, the actual compile behavior between 1.18 and 1.19 shouldn't have changed.

[Gladear]

I'm stumbling upon this issue and I'm a bit astonished by the problem. I spent quite some time cleaning compile-connected cycles in a somewhat large project (find lib -type f | wc -l give me 2630), and verified routes were never an issue. As of today, we have a single compile-connected cycle of 3 files that cannot be removed, but that's it. It's not even related to Phoenix.

Here are two things that helped us most:
First, activate config :phoenix, :plug_init_mode, :runtime in config/dev.exs.
Second, never use

scope "/" do
  get "/users/log_in", AppWeb.UserSessionController, :new
end

but

scope "/", AppWeb do
  get "/users/log_in", UserSessionController, :new
end

which removes the dependency from the router to the controller.

Hope this helps!