Triggering rebuild on config.js change

[davidianbonner]

Enjoying working with the release, good work!

I'd like to propose triggering a rebuild when the config file (tailwind-config.js) is updated if a build tool is being used – ie. webpack.

Basically in the same way as a new build is triggered when you update a css/sass/js file. It would mean that modifications can be made to the config file without having to halt and restart npm watch for instance.

[joshmanders]

I do not believe it's possible as the config is loaded into memory on the webpack side, and webpack doesn't watch it's own config files as it can't restart itself.

[m1guelpf]

How about an abstraction that watches for Laravel Mix (in my case) config changes or tailwind changes and restarts the watch command?

[adamwathan]

This is a super annoying problem and is hard to solve nicely for the reasons @joshmanders mentioned. The best I've figured is to use chokidar-cli to watch the config and restart watch when the config file changes.

Here's an example command you can add to your package.json scripts:

"watch-tailwind": "chokidar 'tailwind.js' --initial=true -c 'npm run watch'",

You'll have to install chokidar-cli first to get that working:

npm install chokidar-cli --save-dev

Changes to your config will result in much slower rebuilds than changes to just your CSS since it has to restart the entire watcher, but it's the best I've come up with so far.

I've also had a few weird situations where it feels like it's building stale versions of things in weird ways and I've had to restart the command manually, but I can't reproduce it reliably and haven't noticed any patterns.

In general, I would recommend trying to avoid editing your config file; ideally you want your config file figured out and more or less "done" at some point, it should be a super low churn file. The workflow shouldn't be "go to config, add utility size I need, go to DOM, add new class"; you want everything already there, otherwise you're just writing CSS again.

One Tailwind anti-pattern that I'd like to warn against in the documentation is starting with a really small/light config file and adding values as you need them. This totally kills the workflow of just designing in the browser with a comprehensive set of utilities, all in the name of prematurely trying to keep your CSS small.

It's better to have more than you need and never have to edit that file and introduce new values into your CSS, then optimize for filesize later IMO. Even then, Tailwind out of the box with a million fucking colors and 5 breakpoints is only 27kb minified and gzipped, which is smaller than just about every image you'll ever serve 😄

[adamwathan]

I'm going to close this as an issue just because there's really nothing we can do about it; we don't have our own watching build tool or anything, we're just the CSS framework.

Happy to keep discussing this though, and we can definitely add some stuff to the documentation if we can come up with some good recommended approaches for people using different tools.

[joshmanders]

It's better to have more than you need and never have to edit that file and introduce new values into your CSS, then optimize for filesize later IMO. Even then, Tailwind out of the box with a million fucking colors and 5 breakpoints is only 27kb minified and gzipped, which is smaller than just about every image you'll ever serve 😄

This right here is why I was so excited for tailwind. Tachyons naming didn't really sit well with me. I really enjoy your naming of every thing having the same name, just prefixed with a size, like tablet:bg-blue instead of something like bg-sm-blue or something.

[davidianbonner]

In general, I would recommend trying to avoid editing your config file; ideally you want your config file figured out and more or less "done" at some point, it should be a super low churn file. The workflow shouldn't be "go to config, add utility size I need, go to DOM, add new class"; you want everything already there, otherwise you're just writing CSS again.

I completely agree, having the ability without reducing the rebuild time would be pretty handy though.

Happy to continue the discussion. Closing the issue makes sense.

For Webpack (with postcss-loader), the config file can be added as a dependency to the messages array. postcss-loader will then add this to Webpack via addDependency (for reference).

I'm doing something similar to the below in another project:

module.exports = postcss.plugin('loadconfig', function (configFile) {
  return function (css, opts) {
      if (fs.existsSync(configFile)) {
        opts.messages = [{
          type: 'dependency',
          file: configFile,
          parent: css.source.input.file,
        }];
      }
    });
  }
});

This will trigger a rebuild if the config file is updated/changed in the exact same manner as a sass/css/js file. I've not noticed any real performance hits in rebuilds with this approach in the past.

I haven't attempted an implementation with gulp though. Normally you specify the files you want watch for changes and the subsequent behaviours manually. Happy to investigate further though.

In the meantime I can create a fork for testing the above with webpack (which will work with laravel mix @m1guelpf)?

[adamwathan]

@davidianbonner Oh wow that's great news! I had thought this was a lost cause from a pure Webpack point of view.

So I've got things rebuilding now whenever the config changes, but the rebuilds don't seem to take into account the new config 🤔

So for example if I add a new color and save the config file, I can see Webpack retriggering in the terminal, but the CSS output doesn't actually contain the new color.

Going to keep hacking on it and try a few things, but if you've got any ideas I'd love to heard them. I'm a complete Webpack novice, so lots of trial and error at the moment, haha...

[adamwathan]

Alright so I've actually got this figured it out and it was a change needed in Tailwind! Going to PR a solution for this soon and probably get it out in a release today.

[davidianbonner]

Excellent.

Was it to do with where the config file was being required. When I was attempting to implement this a while back, I ran into the same issue. Turned out the config file needed to be required inside of the returned function.

module.exports = postcss.plugin('loadconfig', function (configFile) {
  return function (css, opts) {
    config = require(path.resolve(configFile))
    //...
  }
});

[adamwathan]

Yep basically that + explicitly deleting the configFile from the require cache each time it's loaded 👍

[boboldehampsink]

@adamwathan is this still the case for Tailwind 3? It doesn't seem to be reloading automatically