Commit build assets to release branches / tags

[rhcarvalho]

Hi @saadeghi, thanks for daisyUI!

tldr: Would you be open to a contribution adding some automation (scripting + GitHub action) to have the daisyui.js and daisyui-theme.js bundles be part of release tags (in addition to being release assets), or be part of the main branch?

---

For over 5 years (since tailwindlabs/heroicons@a64e81b), Tailwind Heroicons include an optimized directory generated by a build step.

While I don't know the original motivation, it allowed me to contribute a change to the Phoenix framework to track Heroicons by version using Elixir's package manager (mix) instead of requiring users of the framework to manually keep track of versions and update vendored copies, and without the need for Node/npm.

In the next major release, v1.18, Phoenix is adopting daisyUI for newly generated projects. I would like to provide a similar experience to Heroicons, thus being able to pull versioned daisyUI plugin directly from Git/GitHub instead of managing vendored copies.

I understand this change would mostly benefit users outside of the JS ecosystem where npm/yarn/others is often avoided, thus being useful to a broader audience than Elixir/Phoenix developers. For instance, it would make fetching daisyUI with the go CLI trivial, and open up new possibilities for users of the popular Hugo static site generator. Another possible advantage would be having access to any commit/version bundle through GitHub raw files for testing/debugging.

I see there's already a build script that generates the release assets, so I believe the proposed changes wouldn't be too overwhelming. But before spending cycles on it, I'd like to hear your thoughts.

Related:

• Generate static css files for each theme #3048
• Suggestions, feedback and ideas for daisyUI v5 beta #3246 (reply in thread)
• https://daisyui.com/docs/cdn/
• daisyUI for Python #2439

[saadeghi]

Hey 👋
I would be happy to help but I'm not sure if I understood the problem 😅

The files are available for each release. For example 5.0.12:
https://github.com/saadeghi/daisyui/releases/download/v5.0.12/daisyui.js

Or older
https://github.com/saadeghi/daisyui/releases/download/v5.0.11/daisyui.js

Or latest with no version specified
https://github.com/saadeghi/daisyui/releases/latest/download/daisyui.js

Do you mean commiting the file to git? Or adding it to NPM package? Or...?

[rhcarvalho]

Hey thanks for the prompt follow up!

Do you mean commiting the file to git?

Yes, to git -- either keeping it up-to-date with every commit in the main branch, or limit the addition of these files to the commit that gets tagged for the release.

The Elixir package manager mix can download Elixir dependencies from "Hex" (the equivalent of the npm repo for Elixir), or download files straight from a git repo / GitHub (but not releases assets as they are now).

Pointing to some source files that might help make it more tangible:

Template of mix.exs (something like package.json in JS) for new projects, in particular how we pull Heroicons from a GitHub repository:

https://github.com/phoenixframework/phoenix/blob/2e84ac21065cf72d756d444b8fa0a2ce061150e8/installer/templates/phx_single/mix.exs#L51-L57

Current way how daisyUI gets vendored and configured in the app.css entrypoint:

https://github.com/phoenixframework/phoenix/blob/2e84ac21065cf72d756d444b8fa0a2ce061150e8/installer/templates/phx_assets/app.css#L13-L92

I would wish to install daisyUI just like heroicons, by making a shallow sparse clone of the repo (only the bundle dir) and be ready to ship.

---

Disclaimer: I'm an occasional contributor to Phoenix and other projects in the Elixir ecosystem, but not part of the core team / I cannot speak for them. If this idea is welcome here, it would make it viable for me to propose the same simplification I did with heroicons in the past.

[rhcarvalho]

I looked at the automation that is in place for publishing releases:

daisyui/.github/workflows/release-new-version.yml

Lines 45 to 53 in bddedfb

	- name: Build package
	run: bun run --bun build
	- name: Run release command
	run: |
	git config --local user.email "[email protected]"
	git config --local user.name "Pouya Saadeghi"
	cd packages/daisyui
	bunx commit-and-tag-version --infile ../../CHANGELOG.md ${{ inputs.release-type }}

I have the impression that simply removing the .gitignore file from the bundle directory

daisyui/packages/bundle/.gitignore

Lines 1 to 2 in bddedfb

	*.js
	*.mjs

would have the effect of what I'm suggesting: the same bundle files that are published as GitHub releases assets would be available via git checkout.

I recognize that, as per 2f64e50, publishing the bundles is a rather recent addition and still labeled experimental -- so no need to rush anything.

[saadeghi]

Hey,
Yes that's true. It is being generated at build. It's just ignored from git (as you mentioned) because initially I just wanted to upload them as release files.

Noob question:
Just to make sure this is the most efficient way:
How's Tailwind standalone file is being used by Phoenix?
Because that file is also a release attachment (not in git). Right?
Is there a better way to get the file? Like a custom mix task or using curl somehow?

[rhcarvalho]

The current way how Phoenix v1.8-rc0 is implemented, daisyui.js and daisyui-theme.js are vendored in, meaning every newly generated app ships with an outdated version of daisyUI, and the documented way to upgrade is manually running curl, which creates a situation that one can easily end up with versions of those two files that don't match (e.g. by pulling the latest version during a release, or by simply forgetting to change them in lock-step).

My intention is to bring parity with the Heroicons experience, where the version/tag is explicitly stated in mix.exs and the regular mix deps.get command that installs all Elixir dependencies will also take care of pulling in the correct daisyUI bundles.

[rhcarvalho]

In fact, because daisyUI is already a Tailwind plugin, the integration would be better than Heroicons. For Heroicons, there's a small vendored plugin which used to be part of the generated tailwind.config.js file on Tailwind v3, replaced with the plugin in Tailwind v4.

[saadeghi]

Thanks for the explanation.

If Tailwind is being installed using the mix task wrapper you mentioned, and daisyUI is being installed from git (always latest version), is it possible to have a version conflict with feature releases?
For example right now that I'm writing this comment, latest version of Tailwind is 4.1.3, while the mix wrapper installs 4.0.9.

Scenario:
Let's say some day Tailwind CSS adds a new feature in 4.3.0 and daisyUI uses that feature in 5.3.0.
In this case if Tailwind wrapper is installing Tailwind 4.2.x (not latest) and daisyUI is latest (5.3.0) there may be an issue maybe 🤔
This is an imaginary scenario of course and probably won't happen but still possible because minor versions are for features.

Am I being too careful? 😅

[rhcarvalho]

If Tailwind is being installed using the mix task wrapper you mentioned

There are two versions at play here: version of the wrapper and version of tailwind itself.

and daisyUI is being installed from git (always latest version)

No, this is not the case.

Right now version 5.0.x is bundled with every newly generated app, and the documentation suggests upgrading by using curl to download the latest release.

In my proposal, the version of daisyUI would be specified by the Git tag, thus resolving to a fixed commit (same as Heroicons).

---

Since the versions of Tailwind and daisyUI are explicitly defined, users/developers are responsible to pick up compatible versions. In fact, that's one of the cons of using a git dependency in mix.exs, no dependency resolution -- but, the Tailwind wrapper package doesn't solve that either, as it downloads arbitrary versions specified in configuration instead of mix.exs.

Am I being too careful?

I appreciate you being careful -- as I commented earlier, this doesn't need to be a rushed decision.

I have not opened a thread with the Phoenix maintainers yet proposing the change, but I have the precedent of Heroicons.
If you prefer I can go ahead with that as well and try to sync the two threads.

My research yesterday uncovered other ecosystems that might benefit from not needing npm or other JS tooling, such as Python and Go (and I imagine also Ruby/Rails, perhaps others).

[saadeghi]

Thanks for clarifying.
I will add it to git this week ✌️

[rhcarvalho]

A question we might ask ourselves is what sort of problems would committing the bundles to the repo on every release (or at the limit on every change) would bring?

Brainstorming:

• Increased repo size

  Release v5.0.12:

  File	Size
  daisyui-theme.js	45.7 KB
  daisyui-theme.mjs	44.6 KB
  daisyui.js	244 KB
  daisyui.mjs	243 KB

  578 KB per release, ignoring compression.
  For comparison, the full set of optimized heroicon svgs takes 5.1 MB on disk for the latest release.

• Potential for confusion?

• Maintenance pains?

• Noisy git diffs?

[saadeghi]

• Size is ok I'd say.
• Confusion: these files would be the only generated files at git (except changelog.md). Other generated files are on npm only. However the files are going to be on GitHub at /packages/bundle which is separated from the source package so I'd say it's okay.
• no maintenance pain. It's a GitHub action, on release.
• noisy git diff: yeah but it's a generated file anyway — no need to read the diff.

[saadeghi]

🎉 bundle files are now in repo and will be updated after each release: https://github.com/saadeghi/daisyui/tree/master/packages/bundle

[rhcarvalho]

Thanks @saadeghi 💜