Removing Daisy UI from Phoenix

New Phoenix projects ship with Daisy UI by default, but you might want something else. Personally, I’m a fan of the Fluxon UI library and don’t need Daisy. Luckily, it’s really simple to remove Daisy UI from your project.

Start with the CSS file. Open assets/css/app.css and remove the Daisy UI plugin declarations:

@plugin "../vendor/daisyui" { ... }
@plugin "../vendor/daisyui-theme" { ... }

There is two theme declarations, light and dark, that you would want to remove…

Next, clean up the vendor files. Delete these files from assets/vendor/:

• daisyui.js
• daisyui-theme.js

If you want to make it really clean, update the documentation in lib/your_app_web/components/core_components.ex. The module comment mentions Daisy UI and links to their documentation. Remove these references and keep only the Tailwind CSS information.

Run mix assets.build to verify everything compiles. If your build succeeds, you’re done. Your Phoenix app now runs on pure Tailwind CSS without Daisy UI’s component classes and themes.

Local config for Phoenix

Here’s a handy tip: create Phoenix configurations that live only on your machine, not in version control.

I use this for setting machine-specific domain names. It’s ideal for any development settings that shouldn’t live in your shared repository.

First, add this snippet at the bottom of config.exs:

if File.exists?("#{__DIR__}/#{config_env()}.local.exs") do
  import_config "#{config_env()}.local.exs"
end

Create a file named dev.local.exs and Phoenix will load it. Add this to your .gitignore to keep it local:

# Ignore local environment configs
*.local.exs

Your machine-specific settings won’t touch production or bother teammates. Common uses:

• Local database credentials
• Custom domain names (like dev.localhost)
• Local service endpoints
• Personal log levels

Everyone on your team can customize their environment without stepping on each other’s toes. Enjoy!

Domains for local apps

When working on side projects, I prefer setting up a custom domain for each app I’m developing. This approach mimics the production environment more closely and simplifies juggling multiple apps simultaneously.

Using custom domains for local development offers several advantages:

1. It prevents cookie mixing between different apps.
2. It allows for easier configuration of CORS policies.
3. It provides a more realistic testing environment.

Setting this up is straightforward, especially with the help of Caddy. Here’s my process:

First, choose your domain: I typically use the local subdomain. For instance, if my production app is breadandbutter.com, I’ll use local.breadandbutter.com for local development.

Configure Caddy, assuming my local server runs on port 4000, here’s the Caddy configuration I use:

local.breadandbutter.com {
    tls internal
    reverse_proxy localhost:4000
}

Finally, add an A record for local.breadandbutter.com pointing to 127.0.0.1 in my hosts file or local DNS server.

That’s all there is to it! Now I can access my app at local.breadandbutter.com, enjoying the benefits of a custom domain for my local development environment.

This setup not only enhances my development workflow but also helps catch potential issues related to domain-specific configurations early in the development process.

Alias for fast testing in Elixir

In my previous note Shorter feedback loops with Elixir tests I already described how to run tests in Elixir, where it only runs the failed tests. Below is what I put in my mix.exs file to have faster feedback loops when testing:

defp aliases do
    [
      ...
      "test.failed": ["test --failed --max-failures 1"],
    ]
  end

  # Make sure the alias runs in the test MIX_ENV environment.
  def cli do
    [preferred_envs: ["test.failed": :test]]
  end

This will create a new alias test.failed that will run only the failed tests and stop after the first failure. This is useful when you are working on a specific test and you want to run it quickly without running all the tests.