How to refactor for "Aliases could not be expanded for the given types"

[MrYawe]

Since polymorphic_embed 3.0.7 I get this warning:

[warning] Aliases could not be expanded for the given types in [MY STRUCT].

This likely means the types are defined using a module attribute or another reference
that cannot be expanded at compile time. As a result, this may lead to unnecessary
compile-time dependencies, causing longer compilation times and unnecessary
re-compilation of modules (the parent defining the embedded types).

Ensure that the types are specified directly within the macro call to avoid these issues,
or refactor your code to eliminate references that cannot be expanded.

I understand that I must refactor my code to avoid unnecessary compile-time dependencies but I'm not sure how.

Here is how I use polymorphic_embed with a fictional example:

defmodule MyApp.Reminder do
  use Ecto.Schema
  import Ecto.Changeset
  import PolymorphicEmbed
  alias MyApp.Reminder.Channels

  schema "reminders" do
    polymorphic_embeds_one :channel,
      types: Channels.all(),
      on_type_not_found: :raise,
      on_replace: :update
  end
end

defmodule MyApp.Reminder.Channels do
  def all do
    [
      sms: MyApp.Channel.SMS,
      email: MyApp.Channel.Email
    ]
  end
end

The reason why we use a separate module to list all polymorphic_embed types is because we are using it in a lot of different schemas. Can I refactor my code while keeping a single source of truth with all types?

[mathieuprog]

Hi. What does

mix xref graph --label compile-connected --fail-above 0

say for your current code?

[MrYawe]

Thanks for the quick response ❤️

I've found a way to fix it using macros:

defmodule MyApp.Reminder do
  use Ecto.Schema
  import Ecto.Changeset
  import PolymorphicEmbed
  import MyApp.Reminder.Channels

  schema "reminders" do
    embeds_one_channel(:channel)
  end
end

defmodule MyApp.Reminder.Channels do
  @channels [
      sms: MyApp.Channel.SMS,
      email: MyApp.Channel.Email
    ]
    
  defmacro embeds_one_channel(field_name) do
    quote do
      polymorphic_embeds_one(unquote(field_name),
        types: unquote(@channels),
        type_field: :type,
        on_type_not_found: :raise,
        on_replace: :delete
      )
    end
  end
end

[mathieuprog]

@MrYawe Cool:) I'll suggest that snippet to others. Do you confirm though that your compilation was suboptimal through

mix xref graph --label compile-connected --fail-above 0

and that it made a difference?

In other words, is the warning message even right?

[MrYawe]

@mathieuprog From what I'm seeing, there is no difference.

Every schemas (let's call them Reminder1, Reminder2, Reminder3) that has the same polymorphic_embeds_one field with channels types has as compile time dependency to MyApp.Reminder.Channels. Thats seems expected If I understand compilation correctly.

mix xref graph --label compile-connected --fail-above 0

Results before and after:

...
lib/my_app/reminder_1.ex
└── lib/my_app/channels.ex (compile)
lib/my_app/reminder_2.ex
└── lib/my_app/channels.ex (compile)
lib/my_app/reminder_3.ex
└── lib/my_app/channels.ex (compile)
...

[mathieuprog]

It might have been me not understanding the compile-time dependencies:
#85

In which case you refactored for nothing and made your code more complicated for nothing.

I'll make a test project and try to understand better. I added the warning too fast.

[naserca]

@mathieuprog i think this warning is probably a net-negative for the library. curious about your thoughts!

• the MR to expand the aliases is great and necessary: it means the library itself is not causing unnecessary compile-time deps. thank you!
• the warning however is trying to do the job of mix xref from a place of incomplete information. as the warning itself implies, it may be inaccurate.
• this is why ecto and phoenix and oban and other libs who expand like this don't try to warn in cases like "set a module attribute, use it." (in fact, the example in the comments here doesn't actually cause a compile-time dep.) instead they leave it to the compiler and mix xref to let the eng know if there's a problem.
• in the case of false positives, the warning scares engineers unnecessarily. we are experiencing this :)
• i could imagine some fancy "ignore" tag or something to suppress the warning, but really i think these kinds of warnings, failures, etc, should be left to compiler and related tooling.

what do you think? should i open an MR to remove entirely?

[naserca]

@mathieuprog I opened this MR to remove the warning: #123 🙏