Passing additional content paths to tailwindcss

Created on 13 July 2023, over 1 year ago
Updated 2 October 2023, about 1 year ago

Problem/Motivation

It would be useful to be able to provide additional content paths for Tailwind to scan when compiling CSS. The main use case for this is to include additional Tailwind classes used in JS files, whether from custom scripts or from component libraries such as Flowbite or Tailwind Elements.

Proposed resolution

I think it makes more sense to configure this in a YML file as suggested in https://www.drupal.org/project/tailwind_jit/issues/3374341 Using a YML file to configure settings Active . We can just add an array with the additional content paths to pass to the Tailwind cli during compilation.

Remaining tasks

User interface changes

API changes

Data model changes

Feature request
Status

Closed: won't fix

Version

1.0

Component

Code

Created by

🇭🇰Hong Kong phparkle

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @phparkle
  • 🇦🇹Austria hudri Austria

    I can see the need and the use case, but one issue boggles me. AFAIK the CLI only supports shell wildcards, but not the JS globbing patterns. So things like

    module.exports = {
      content: [
        './pages/**/*.{html,js}',
        './components/**/*.{html,js}',
      ],
    }
    

    will not work in a YAML/CLI config. I'm not using component libs, but I fear one would have to list dozen of component directories here one by one.

  • 🇭🇰Hong Kong phparkle

    I gave this some more thought and it realized that it doesn't make much sense to rescan the same static assets on every single (uncached) request...

  • Status changed to Closed: won't fix over 1 year ago
  • 🇦🇹Austria hudri Austria

    Closing as per #3

    Just for reference:

    Classes/styles dynamically generated on client side are not (and can not) be detected by this module, because by design this module only inject styles rendered on server side. Workaround for fully client side generated styles are either Tailwind's safelist config option

    /* tailwind.config.js */
    module.exports = {
      ...,
      safelist: [
        'bg-red-500',
        'text-3xl',
        'lg:text-4xl',
      ],
      ...,
    }
    

    or you can create kind of "dynamic safelist" by including a hidden div in your template, e.g.

    {# node_with_external_js_library.html.twig #}
    <div {{ atributes }}>
      <div id="placehoder_rendered_on_clientside_by_js_lib"></div>
    </div>
    {{ attach_library('my_module/clientside_js_rendering') }}
    <div class="!hidden bg-red-500 text-3xl lg:text-4xl">this works like a dynamic safelist</div>
    
  • Status changed to Active over 1 year ago
  • 🇦🇹Austria hudri Austria

    I'm re-opening that ticket because the same idea can be used to include CKeditor text styles into the safelist. Instead of manually adding classes into Tailwind's safelist, the module could automatically scan ~/config/sync/editor.editor.*.yml for styles used in WYSIGWYG editor formats.

  • Status changed to Closed: won't fix about 1 year ago
  • 🇦🇹Austria hudri Austria

    After playing around with in our own projects, I'm going to close this again. Combining this module with a list of content/template files is counter-productive and just leads to very slow compile times and bloated CSS.

    TailwindCSS' content list is meant to be used as a reducer/purger for CSS, not to add additional rules. To add additional classes/rules to your CSS, use Tailwind's safelist feature instead.

Production build 0.71.5 2024