An Igniter Saga - Generating Code for Agency Projects

Heyo @zachdaniel!

This topic continues a conversation that started in the Igniter topic.

The component generators turned out nicely, and I can’t wait to use them on new projects. :tada: I’m working on a new generator for adding Commanded and related config to projects.

When I attempt to add config for a module within my app, the generated config is appended to the top-level app config with string atoms as the keys. What I was expecting was a separate block of config with the module as the second argument, followed by the KW list.

Am I doing something wrong, or is this a possible bug?

Expected

config :yolo,
  ecto_repos: [Yolo.Repo],
  generators: [timestamp_type: :utc_datetime],
  consistency: :eventual,
  event_stores: [Yolo.EventSystem.EventStore]

config :yolo, Yolo.EventSystem.EventStore,
    migration_primary_key: [type: :binary_id],
    migration_foreign_key: [type: :binary_id],
    migration_timestamps: [type: :utc_datetime_usec]

config :yolo, Yolo.EventSystem.Application,
    event_store: [
      adapter: Commanded.EventStore.Adapters.EventStore,
      event_store: Yolo.EventSystem.EventStore
    ],
    phoenix_pubsub: [adapter: Phoenix.PubSub.PG2, pool_size: 1],
    pubsub: :local,
    registry: :local,
    snapshotting: %{}

Actual

config :yolo,
  ecto_repos: [Yolo.Repo],
  generators: [timestamp_type: :utc_datetime],
  consistency: :eventual,
  event_stores: [Yolo.EventSystem.EventStore],
  "Elixir.Yolo.EventSystem.EventStore": [
    migration_primary_key: [type: :binary_id],
    migration_foreign_key: [type: :binary_id],
    migration_timestamps: [type: :utc_datetime_usec]
  ],
  "Elixir.Yolo.EventSystem.Application": [
    event_store: [
      adapter: Commanded.EventStore.Adapters.EventStore,
      event_store: Yolo.EventSystem.EventStore
    ],
    phoenix_pubsub: [adapter: Phoenix.PubSub.PG2, pool_size: 1],
    pubsub: :local,
    registry: :local,
    snapshotting: %{}
  ]

Igniter Code

igniter
|> Igniter.compose_task("cauldron.install.ecto", [])
|> Igniter.Project.Deps.add_dep({:commanded, "~> 1.4"})
|> Igniter.Project.Deps.add_dep({:commanded_ecto_projections, "~> 1.4"})
|> Igniter.Project.Deps.add_dep({:commanded_eventstore_adapter, "~> 1.4"})
|> Igniter.apply_and_fetch_dependencies(yes: true)
|> Igniter.Project.Config.configure("config.exs", app_name, :consistency, :eventual)
|> Igniter.Project.Config.configure("config.exs", app_name, :event_stores, [
  event_store_module
])
|> Igniter.Project.Config.configure(
  "config.exs",
  app_name,
  event_store_module,
  migration_primary_key: [type: :binary_id],
  migration_foreign_key: [type: :binary_id],
  migration_timestamps: [type: :utc_datetime_usec]
)
|> Igniter.Project.Config.configure(
  "config.exs",
  app_name,
  event_system_application_module,
  event_store: [
    adapter: Commanded.EventStore.Adapters.EventStore,
    event_store: event_store_module
  ],
  phoenix_pubsub: [
    adapter: Phoenix.PubSub.PG2,
    pool_size: 1
  ],
  pubsub: :local,
  registry: :local,
  snapshotting: %{}
)

Module Variables at Runtime

Running the command in the :yolo sandbox app, these are the values used for the config path:

event_store_module = Yolo.EventSystem.EventStore
event_system_application_module = Yolo.EventSystem.Application

After generating a new config block with module names rendered as proper atoms, this does appear to be a bug. I opened #104 in the repo for this.

:bowing_man: thanks! I’ll take a look :slight_smile:

1 Like

Fixed :smiley:

1 Like

Excellent! :fire::fire::fire: I will give it a shot tomorrow.

1 Like

@zachdaniel Congrats on releasing the update feature!

I’m rewriting a Mix.Task with Igniter, and I’m curious what Igniter.Mix.Task.Info.aliases would do and how to use it. I’m guessing this is where short options would go a la --migration-m. Is that right?

Do you have an example?

1 Like

Yes, that is correct. It’s used with OptionParser, so -m would be used as m: :migration, for example.

1 Like