Hanami and Tailwind à la Decaf Sucks

questions
1

Hi :wave:

I’m setting up Tailwind/daisyUI for my pet project and some recent commits by @timriley are a really good starting point. However, there are two details I don’t quite understand, maybe somebody can shed some light?

  • PR 25 adds assets.mjs, but Hanami 2.1 bootstraps assets.js. I don’t see any functional differerence, does it matter at all?
  • PR 26 adds postcss and autoprefixer to the mix as (runtime) dependencies. Any reason why not as devDependencies and why not included via tailwind.config.js?

Oh, time for the dog walk and some fullcaf coffee on the way. :dog: Thanks for your help!

2

Hey @svoop! Hope you’ve had a good leg stretch and the coffee is kicking in now :slight_smile:

I made this PR before the final release of 2.1.0, which is why there’s a subtle difference of naming. As of 2.1.0, however, we expect config/assets.js only, and we generate a "type": "module" into the default package.json to make sure this file uses ECMAScript Modules.

The reason that dependencies like these need to go into dependencies instead of devDependencies is that they need to be installed for hanami assets compile to run as part of an app’s deployment process.

3

Hi @timriley

Thanx a bunch for your reply!

Hope you’ve had a good leg stretch and the coffee is kicking in now

I guess you can call me an addict when it comes to good coffee, kind of our hobby when we’re on the roam. And the trend keeps spreading, one of the best roastaries we came across is located way above the polar circle in northern Norway – run by an Australian. :slight_smile:

they need to be installed for hanami assets compile to run as part of an app’s deployment process.

I see. Shouldn’t Tailwind also be a runtime dependency then?

Or maybe install Tailwind as a PostCSS plugin| instead of the Tailwind CLI? (Not the other way around as I mistakenly wrote above.)

Cheers!

4

Yes, it should! With decafsucks I haven’t yet got to the point of deploying it anywhere, which is why I haven’t made that change there yet.

5

I’ve go it mostly working, however, there’s one caveat:

When Tailwind is installed via PostCSS, the assets are not rebuilt when a utility class is changed in a template – assets only watch the assets dir.

Is there a way to add paths to be watched for rebuilding assets? Or as a plan B a way to trigger an assets rebuild for development (which could be added to the Guardfile)? hanami assets compile doesn’t cut it since it adds the fingerprints.

Thanks again for your help!

6

@timriley First of all, congrats to 2.2, love to use the new persistence!

A few hundred ^C dev down the road, do you maybe have an idea how to tackle my rebuild gotcha from my preceding comment, the one starting with “I’ve go it mostly working, however, there’s one caveat:”?

Cheers!

7

Hey @svoop, thanks for the kind words. I’m very glad to have 2.2 out!

You’ve probably seen this in decafsucks and decided it isn’t right for you, but let me just check: have you seen the rake tailwind:watch task in decafsucks?

It uses the tailwind CLI (via npx tailwindcss) and combined with this tailwind.config.js, it watches for changes to template files and rebuilds the CSS to match.

Would that solve it for you?

8

I could get things to work with Tailwind via PostCSS but had to tweak the Guardfile like so:

# frozen_string_literal: true

require 'guard/compat/plugin'

module ::Guard
  class Postcss < Plugin

    def initialize(options = {})
      super(options)
    end

    def run_on_modifications(paths)
      `bundle exec hanami assets compile`
    end
  end
end

group :server do
  guard "puma", port: ENV.fetch("HANAMI_PORT", 2300) do
    watch(%r{^(app|config|lib|slices)/.+\.(rb|erb)$}i)
  end

  guard "postcss" do
    watch(%r{^(app|slices)/.+\.(rb|erb)$}i)
  end
end

This way, the Tailwind CSS is built as part of esbuild which is nice, but the Guardfile (which rebuilds all assets on every change) and the dependency on PostCSS seem overly complicated in retrospect.

So I stripped things down more like Decafsucks. It seems to be the better approach not to produce too much asset compile overhead in development. The speed is not a problem now, but it could be tomorrow.

Thanks for your help!