There are no plans to extract it at the moment but I also want to point out that “without pulling LiveView related code that I don’t use” is most likely a micro-optimization. I just checked LiveView source code and at the moment it defines 57 modules. Plus a quick estimate shows that roughly half of these modules (~28) have Engine/HEEx functionality. That is tiny compared to the number of modules you will have in your application. For example, Livebook has 959 modules, and that’s not counting the ones coming from Elixir or Erlang/OTP. Therefore, it is hard to see how “not pulling LiveView-related code” is going to give any meaningful benefit.
One could argue that, if you don’t care about LiveView, having to debug only the HEEx bits is going to be easier, and I would agree with that. But that comes at the cost of putting a layer (and a dependency) between LiveView and HEEx, which will make the lives of everyone using, maintaining, and debugging LiveView - which is perhaps the majority - much harder. So the costs are really hard to justify here.
And it is not like we are averse with breaking things apart. We extracted Phoenix.HTML, Phoenix.PubSub, and Phoenix.View/Template (the latter pretty much based on user demand) in the past. And it actually has led to the downside of fragmenting the documentation - which is a complaint that needs to be addressed… So breaking LV+HEEx might happen in the future but 99% not worth it now.
