Skip to content

installer: manage daisyui via mix.exs#6713

Open
rhcarvalho wants to merge 2 commits into
phoenixframework:mainfrom
rhcarvalho:daisyui-versioned-through-mix
Open

installer: manage daisyui via mix.exs#6713
rhcarvalho wants to merge 2 commits into
phoenixframework:mainfrom
rhcarvalho:daisyui-versioned-through-mix

Conversation

@rhcarvalho

Copy link
Copy Markdown
Contributor

Similar to how we replaced vendored Heroicons with a Git/GitHub Mix dependency, replace the vendored daisyUI with a mix dependency.

This offers a few benefits:

  • Improved supply chain awareness (easily verify which version is in use)
  • Easier updates by bumping a tag in mix.exs
  • Avoids bloating the installer templates, new apps, Docker images, etc, with large static files

See:

@rhcarvalho rhcarvalho force-pushed the daisyui-versioned-through-mix branch from 361448b to 66d9a28 Compare June 12, 2026 21:50
@rhcarvalho

Copy link
Copy Markdown
Contributor Author

Error: No space left on device : '/home/runner/actions-runner/extracted/_diag/pages/d2c730dc-5517-468a-a7ce-970d6630157c_33d64cf1-7383-5635-8374-a01037543bdb_1.log'

https://github.com/phoenixframework/phoenix/actions/runs/27445073432/job/81128074157?pr=6713#step:4:1211

Ooops?! 🤷

@SteffenDE

Copy link
Copy Markdown
Member

Yeah, looks like the daisyUI repo is very large and the older version doesn't support shallow checkouts?

@rhcarvalho

Copy link
Copy Markdown
Contributor Author

Oh, so that would explain the failure! How unfortunate, save disk space in one move, use lots of disk space elsewhere.

While Phoenix itself supports older versions, does the installer (mix phx_new) has to operate on the same version constraints?

I don't have the data, but would imagine all the incentives are to start a greenfield project on a more recent version (1.18-1.20).

@rhcarvalho

Copy link
Copy Markdown
Contributor Author

Shallow clones is from 1.17:

"[mix deps] Add :depth option to Mix.SCM.Git, thus supporting shallow clones of Git dependencies"
https://hexdocs.pm/elixir/changelog.html#:~:text=%5Bmix%20deps%5D%20Add%20%3Adepth%20option%20to%20Mix.SCM.Git%2C%20thus%20supporting%20shallow%20clones%20of%20Git%20dependencies

https://mix.hexdocs.pm/1.20.1/Mix.Tasks.Deps.html#module-git-options-git

Sparse checkouts much earlier.

@rhcarvalho

rhcarvalho commented Jun 14, 2026

Copy link
Copy Markdown
Contributor Author

phoenix/mix.exs

Lines 14 to 17 in 811a849

# If the elixir requirement is updated, we need to make the installer
# use at least the minimum requirement used here. Although often the
# installer is ahead of Phoenix itself.
@elixir_requirement "~> 1.15"

@rhcarvalho

Copy link
Copy Markdown
Contributor Author

@SteffenDE saadeghi/daisyui#3834, saadeghi/daisyui#2997, the large repo size is a known "issue". I didn't recall it.

One way around would be a fork, or fork + github action to pull updates, but then we're defeating the ability to point straight upstream instead of maintaining a level of indirection. At that point we could have an auto-published Hex package as well.

@rhcarvalho

Copy link
Copy Markdown
Contributor Author

For reference, the requirement of 1.15+ in the installer dates back to Oct 2024 (#5957)

@SteffenDE

Copy link
Copy Markdown
Member

Yeah, it’s probably fine to bump the requirement for new apps.

cc @josevalim

@josevalim

Copy link
Copy Markdown
Member

Yes, it is fine to bump it for new apps!

@rhcarvalho

Copy link
Copy Markdown
Contributor Author

@SteffenDE @josevalim rebased on top of main (to pick up recent CI changes) and bumped the Elixir version requirement for the installer and new apps in a separate commit for easier review. The patch in the original commit has not changed.

Unfortunately I think in https://github.com/phoenixframework/phoenix/actions/runs/27549626721/job/81432108238?pr=6713 we ran into elixir-lang/elixir#14425, untracked files in CI cache affecting mix deps.get. A fix for that was released in Elixir 1.19.

Any suggestions? Both sound non-ideal to me:

  1. Manually rm -rf deps/daisyui in the CI job before running mix deps.get
  2. Requiring Elixir v1.19

If nothing else, I'd pick 1 with a note to remove the hack once we require Elixir v1.19+.

@josevalim

Copy link
Copy Markdown
Member

1 sounds good!

Similar to how we replaced vendored Heroicons with a Git/GitHub Mix
dependency, replace the vendored daisyUI with a mix dependency.

This offers a few benefits:
- Improved supply chain awareness (easily verify which version is in use)
- Easier updates by bumping a tag in mix.exs
- Avoids bloating the installer templates, new apps, Docker images, etc, with large static files

See:
- saadeghi/daisyui#3749
- phoenixframework#5622
While the installer itself doesn't depend on Elixir v1.17, it would be a
strange UX to use say Elixir v1.15 to scaffold an app just to realize
you cannot run the generated app without upgrading.

Requiring Elixir v1.17 ensures every supported version can handle the
`:depth` option for Git Mix dependencies, required for shallow clones.
This feature is used both for heroicons and daisyui, and is fundamental
for daisyui as otherwise cloning the repository incurs over 10 GB of
disk space.
@rhcarvalho rhcarvalho force-pushed the daisyui-versioned-through-mix branch 3 times, most recently from c857194 to a45b9c6 Compare June 15, 2026 15:12
@rhcarvalho

Copy link
Copy Markdown
Contributor Author

Unfortunately I think in https://github.com/phoenixframework/phoenix/actions/runs/27549626721/job/81432108238?pr=6713 we ran into elixir-lang/elixir#14425, untracked files in CI cache affecting mix deps.get. A fix for that was released in Elixir 1.19.

Sorry, I made a mistake. It turns out I let the wrong daisyui commit hash slip into phoenix/integration_test/mix.lock (I'm intentionally sticking to v5.5.20 and not bumping it as part of this change (current latest is v5.5.23).

The deps hack (c857194) might not be necessary.

@rhcarvalho

Copy link
Copy Markdown
Contributor Author

This is ready for a final review. It's the original implementation + bumping version requirement for installer and new apps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants