Thank you for your replying @cvkmohan. Indeed, the package looks really good. I tried to set it up as a dependency in my project and I got a mismatch between dependencies, as you can see below. Any thoughts?
Failed to use "phoenix_html" (versions 3.0.0 and 3.0.1) because
apps/habitus_web/mix.exs requires ~> 3.0
ex_fontawesome (version 0.3.0) requires ~> 2.14
phoenix_ecto (version 4.4.0) requires ~> 2.14.2 or ~> 3.0
phoenix_live_view (version 0.16.0) requires ~> 3.0.0
phoenix_live_view (version 0.16.1) requires ~> 3.0
Failed to use "phoenix_html" (versions 3.0.0 to 3.0.2) because
apps/habitus_web/mix.exs requires ~> 3.0
ex_fontawesome (version 0.3.0) requires ~> 2.14
phoenix_ecto (version 4.4.0) requires ~> 2.14.2 or ~> 3.0
phoenix_live_view (version 0.16.1) requires ~> 3.0
Failed to use "phoenix_html" (version 3.0.2) because
apps/habitus_web/mix.exs requires ~> 3.0
ex_fontawesome (version 0.3.0) requires ~> 2.14
phoenix_ecto (version 4.4.0) requires ~> 2.14.2 or ~> 3.0
phoenix_live_view (version 0.16.0) requires ~> 3.0.0
** (Mix) Hex dependency resolution failed, change the version requirements of your dependencies or unlock them (by using mix deps.update or mix deps.unlock). If you are unable to resolve the conflicts you can try overriding with {:dependency, "~> 1.0", override: true}
Sure I get it. I’m not a Phoenix maintainer but from the issue stats (npm was 591 out of 2034 
) it looks like a clear line had to be drawn to indicate that Phoenix support cannot and doesn’t cover npm - which it has every right to, offering 1st class support for plugging any bundler. I suppose these sorts of lines are thinner with frameworks than with regular libs.
) but I personally wouldn’t put even a single lib (e.g. topbar) into my project by copy-pasting because I’ve been there years ago and it’s just never worth it. And realistically, you’ll always want at least few more NPM packages in about every non-API project.
