v4: tailwindcss:watch not working after using the upgrade tool

[drale2k]

As mentioned in #450 (comment), the tailwindcss:watch command is no longer working for me after the upgrade to v4. The cause is having the @config directive present in the application.tailwind.css file used for backwards compatibility - as mentioned here #450 (reply in thread)

Everything seems to work after i removed it but i believe the upgrade script automatically added both lines to application.tailwind.css:

@import 'tailwindcss';
@config '../../../config/tailwind.config.js';

23:30:53 web.1    | => Booting Puma
23:30:53 web.1    | => Rails 8.0.1 application starting in development 
23:30:53 web.1    | => Run `bin/rails server --help` for more startup options
23:30:53 web.1    | Puma starting in single mode...
23:30:53 web.1    | * Puma version: 6.5.0 ("Sky's Version")
23:30:53 web.1    | * Ruby version: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24]
23:30:53 web.1    | *  Min threads: 3
23:30:53 web.1    | *  Max threads: 3
23:30:53 web.1    | *  Environment: development
23:30:53 web.1    | *          PID: 43869
23:30:53 web.1    | * Listening on http://127.0.0.1:3000
23:30:53 web.1    | * Listening on http://[::1]:3000
23:30:53 web.1    | Use Ctrl-C to stop
23:30:53 worker.1 | 
23:30:53 worker.1 | [GoodJob] [43871] GoodJob 4.8.0 started scheduler with queues=fast max_threads=3.
23:30:53 worker.1 | [GoodJob] [43871] GoodJob 4.8.0 started scheduler with queues=default,fast max_threads=5.
23:30:53 worker.1 | [GoodJob] [43871] GoodJob 4.8.0 started scheduler with queues=* max_threads=5.
23:30:53 worker.1 | [GoodJob] GoodJob started cron with 2 jobs.
23:30:53 worker.1 | [GoodJob] Notifier subscribed with LISTEN
23:30:54 css.1    | exited with code 0
23:30:54 system   | sending SIGTERM to all processes
23:30:54 web.1    | - Gracefully stopping, waiting for requests to finish
23:30:54 web.1    | Exiting
23:30:54 web.1    | terminated by SIGTERM
23:30:55 web.1    | exited with code 0

I am not sure yet if removing the old config has any side effects and how it affects the plugins loaded through the config.

[flavorjones]

@drale2k I'm sorry, I still cannot reproduce what you're seeing, and I need more information from you about your setup in order to reproduce this.

As an example of the type of information I'm looking for ...

I've tried reproducing this upgrading the gem from tailwindcss-rails v3.3.0 and tailwindcss-ruby v3.4.17 to tailwindcss-rails a0eaafa and tailwindcss-ruby v4.0.0.

I've done this with both a Rails 7.2.2.1 app and a Rails 8.0.1 app.

I have a script that is run in CI to set up the upgrade scenario, which you can run on your machine if you like: test/integration/user_upgrade_test.sh.

In the Rails 8 app, here's the output from running bin/dev right after the upgrade:

$ bin/dev
14:08:38 web.1  | started with pid 2382659
14:08:38 css.1  | started with pid 2382660
14:08:39 web.1  | => Booting Puma
14:08:39 web.1  | => Rails 8.0.1 application starting in development
14:08:39 web.1  | => Run `bin/rails server --help` for more startup options
14:08:39 web.1  | Puma starting in single mode...
14:08:39 web.1  | * Puma version: 6.5.0 ("Sky's Version")
14:08:39 web.1  | * Ruby version: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [x86_64-linux]
14:08:39 web.1  | *  Min threads: 3
14:08:39 web.1  | *  Max threads: 3
14:08:39 web.1  | *  Environment: development
14:08:39 web.1  | *          PID: 2382659
14:08:39 web.1  | * Listening on http://127.0.0.1:3000
14:08:39 web.1  | * Listening on http://[::1]:3000
14:08:39 web.1  | Use Ctrl-C to stop
14:08:39 css.1  | sh: 1: watchman: not found
14:08:39 css.1  | ≈ tailwindcss v4.0.0
14:08:39 css.1  |
14:08:39 css.1  | Done in 88ms
14:08:52 css.1  | Done in 308µs
14:08:52 css.1  | Done in 308µs
14:08:56 css.1  | Done in 1ms
14:08:56 css.1  | Done in 2ms
^C14:12:53 system | SIGINT received, starting shutdown
14:12:53 web.1  | - Gracefully stopping, waiting for requests to finish
14:12:53 web.1  | === puma shutdown: 2025-01-26 14:12:53 -0500 ===
14:12:53 web.1  | - Goodbye!
14:12:53 web.1  | Exiting
cd 14:12:54 system | sending SIGTERM to all processes
14:12:54 web.1  | exited with code 0
14:12:54 css.1  | exited with code 0

Note that each of those "Done in ..." lines is me making a local edit to app/views/posts/index.html.erb and the watch command picking it up. And the SIGINT is me hitting Ctrl-C in the terminal to shut everything down.

Same output for the Rails 7.2.2.1 app:

$ bin/dev
14:13:07 web.1  | started with pid 2385406
14:13:07 css.1  | started with pid 2385407
14:13:08 web.1  | => Booting Puma
14:13:08 web.1  | => Rails 7.2.2.1 application starting in development
14:13:08 web.1  | => Run `bin/rails server --help` for more startup options
14:13:08 web.1  | Puma starting in single mode...
14:13:08 web.1  | * Puma version: 6.5.0 ("Sky's Version")
14:13:08 web.1  | * Ruby version: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [x86_64-linux]
14:13:08 web.1  | *  Min threads: 3
14:13:08 web.1  | *  Max threads: 3
14:13:08 web.1  | *  Environment: development
14:13:08 web.1  | *          PID: 2385406
14:13:08 web.1  | * Listening on http://127.0.0.1:3000
14:13:08 web.1  | * Listening on http://[::1]:3000
14:13:08 web.1  | Use Ctrl-C to stop
14:13:08 css.1  | sh: 1: watchman: not found
14:13:08 css.1  | ≈ tailwindcss v4.0.0
14:13:08 css.1  |
14:13:08 css.1  | Done in 84ms
14:13:19 css.1  | Done in 230µs
14:13:19 css.1  | Done in 585µs
14:13:21 css.1  | Done in 1ms
14:13:21 css.1  | Done in 2ms
^C14:13:24 system | SIGINT received, starting shutdown
14:13:24 web.1  | - Gracefully stopping, waiting for requests to finish
14:13:24 web.1  | === puma shutdown: 2025-01-26 14:13:24 -0500 ===
14:13:24 web.1  | - Goodbye!
14:13:24 web.1  | Exiting
14:13:24 system | sending SIGTERM to all processes
14:13:24 web.1  | exited with code 0
14:13:25 css.1  | exited with code 0

Can you please help me understand how to reproduce what you're seeing?

[flavorjones]

I've also tried to reproduce this upgrading to tailwindcss-rails v4.0.0.rc1 running the same script as above. It works fine for me.

The contents of my application.tailwind.css file in this case is:

@import 'tailwindcss';

@config '../../../config/tailwind.config.js';

/*

@layer components {
  .btn-primary {
    @apply py-2 px-4 bg-blue-200;
  }
}

*/

/*
  The default border color has changed to `currentColor` in Tailwind CSS v4,
  so we've added these compatibility styles to make sure everything still
  looks the same as it did with Tailwind CSS v3.

  If we ever want to remove these styles, we need to add an explicit border
  color utility to any element that depends on these defaults.
*/
@layer base {
  *,
  ::after,
  ::before,
  ::backdrop,
  ::file-selector-button {
    border-color: var(--color-gray-200, currentColor);
  }
}

[drale2k]

Thanks for taking a look. I will gather together notes of my upgrade version path and post them. Can i see your bin/dev? Are you using foreman?

This is my bin/dev:

#!/usr/bin/env sh

if ! gem list foreman -i --silent; then
  echo "Installing foreman..."
  gem install foreman
fi

# Default to port 3000 if not specified
export PORT="${PORT:-3000}"

# Let the debug gem allow remote connections,
# but avoid loading until `debugger` is called
export RUBY_DEBUG_OPEN="true"
export RUBY_DEBUG_LAZY="true"

exec foreman start -f Procfile.dev "$@"

My Procfile.dev:

web: bin/rails server
worker: bundle exec good_job --queues="fast:3;default,fast:5;*:5"
css: bin/rails tailwindcss:watch

How does running bin/rails tailwindcss:watch directly in the terminal behave for you? When i run it, it just returns without any output or error. Seemingly doing nothing

[flavorjones]

You can run the script I pointed to above to reproduce my setup exactly, if you want.

My bin/dev is stock:

#!/usr/bin/env sh

if ! gem list foreman -i --silent; then
  echo "Installing foreman..."
  gem install foreman
fi

# Default to port 3000 if not specified
export PORT="${PORT:-3000}"

# Let the debug gem allow remote connections,
# but avoid loading until `debugger` is called
export RUBY_DEBUG_OPEN="true"
export RUBY_DEBUG_LAZY="true"

exec foreman start -f Procfile.dev "$@"

My Procfile is stock:

web: bin/rails server
css: bin/rails tailwindcss:watch

Running bin/rails tailwindcss:watch works fine for me.

If you've narrowed things down to whether your config file is included or not, what's in your config/tailwind.config.js file? Here's mine:

// const defaultTheme = require('tailwindcss/defaultTheme')

module.exports = {
  content: [
    './public/*.html',
    './app/helpers/**/*.rb',
    './app/javascript/**/*.js',
    './app/views/**/*.{erb,haml,html,slim}'
  ],
  theme: {
    extend: {
      fontFamily: {
//         sans: ['Inter var', ...defaultTheme.fontFamily.sans],
      },
    },
  },
  plugins: [
    // require('@tailwindcss/forms'),
    // require('@tailwindcss/typography'),
    // require('@tailwindcss/container-queries'),
  ]
}

[drale2k]

I got it.. thanks to your posted tailwind.config.js. I did not have the plugins commented out as you have and since i am running a nobuild setup using importmaps, i did not have the plugins installed as packages. I guess when the watch process was trying to start, it detected that and just stopped. Weird that it does not throw an error.

It all makes sense now. I load the plugins via the new @plugin directive instead https://tailwindcss.com/docs/functions-and-directives#plugin-directive.

After commenting out the listed plugins as you did, it works. Thanks a lot

[drale2k]

Actually what i wrote is wrong. I do have them installed but i dod so with npm, globally. That's the only way @plugin can find them. So i guess what it boils down to is that when declared in config/tailwind.config.js, they cannot be found but using the @plugin directive they can

[drale2k]

Actually what i wrote is wrong. I do have them installed but i dod so with npm, globally. That's the only way @plugin can find them. So i guess what it boils down to is that when declared in config/tailwind.config.js, they cannot be found but using the @plugin directive they can

Quick correction on this one: I deployed to prod, only using the @plugin directive - without any package manager and the plugins work just fine. I did not need to install anything using a JS package manager. I only use importmaps and this gem, nothing else.

[flavorjones]

Thanks for the notes, @drale2k. I'm going to close this, since I don't think there's anything we can do in this gem except document these behaviors in the README which I think @EricGusmao has offered to do.

But if you have more questions, please ask here or in the Discussions thread. 🙏

[drale2k]

Thanks for the help, all working now