Plugin system using compiled Tailwind CSS files?

[adrianthedev]

Updated: Compiled files scenario

Hey,

I'm trying to build a plugin system in Rails which ships the compiled Tailwind CSS for the Main app and each plugin.

I don't want to force the user of our product to run a Tailwind build command.

Entities

• The main app - it's a Rails app which has it's own CSS pipeline.
• The product (https://github.com/avo-hq/avo) - is a plugin for the Rails app. A library which should come with the assets already compiled. It doesn't require a build step to use the CSS which is based on TailwindCSS
• The plugins for Avo - Each plugin is a library that the user installs using the package manager (bundler - similar to npm). Each plugin should ship with its CSS compiled using TailwindCSS.

Avo should be able to load its CSS (compiled using Tailwind) and all of the plugins' CSS (still compiled with Tailwind) and not have clashes and specificity conflicts.

When Avo loads both compiled CSS files we end up with specificity conflicts from the two files (Avo and plugin 1).

The question

How could I build that plugin system and have it be safe and contain all the compiled classes from the main app and all the plugins to play well together?

Thanks!

Original question

Hey,

I'm trying to build a plugin system in Rails which ships the compiled Tailwind CSS for each plugin.
That's rather easy to do.

The more difficult thing is to ensure that the build system on the main app (which uses the plugins) keeps the plugins classes in the compiled output.

Example

We have a Main app (Rails) which loads Plugin 1. The main app has a Tailwind build system which does its thing (scans the project and keeps the used classes).

Plugin 1 has a divide-y class somewhere in a component. We ship that class inside a component (https://github.com/ViewComponent/view_component) so the Main app does not see or scan the plugin structure and thus, it can't see the divide-y class and strips it out.

Initial solution

We had a Tailwind build process in both the main app and the plugin and when we ran the project, we loaded both output tailwind files (the compiled ones with the final CSS).
That proved to not be ok because we would have clashes and specificity issues between them.
This goes bad really fast when you add more plugins to the mix.

Potential solution

What we could do is to have a Tailwind build system in the library which finds the used classes and outputs them to a plugin-safelist.txt file and then the main app would see those classes in the safelist and keep them in the final output.

I mean, the tailwind CLI already scans the whole content from plugin 1 and knows which classes it needs to keep. Could we have a flag or command to export them to a file?

The question

How could I build that plugin system and have it be safe and contain all the compiled classes from the main app and all the plugins to play well together?

FAQ

1. You may wonder why it does not scan the plugin structure. The reason is that the plugin is shipped as a library and is not in the project directory (similar to how it wouldn't scan node_modules for libraries).

Thanks!

[wongjn]

You may wonder why it does not scan the plugin structure. The reason is that the plugin is shipped as a library and is not in the project directory (similar to how it wouldn't scan node_modules for libraries).

Does the plugin install in a consistent directory relative to the project, like node_modules? If so, you could use @source to enforce that Tailwind scans the installed plugin from the main app.

Otherwise, if the plugin would not install in a consistent directory, consider if there is some way to symlink it inside the project. In this case, presumably, the project has some way to read the plugin code, so perhaps use the same logic to perform some kind of post-install script to symlink the plugin inside the project to a consistent directory. Then you should be able to use @source as mentioned above (if needed at all in this case).

[adrianthedev]

Thanks, Justin.

I kinda figured out that our problem is with shipping them as compiled already...

[rozsazoltan]

Related:

• Adding an external source or a package from within node_modules for detection
• All components from the UI package are included in the project's generated CSS, but I don't use every component

[adrianthedev]

Thanks for the suggestion, Zoltán. We actually need to mix them both as compiled.

[adrianthedev]

I'll definitely have a look over them

[adrianthedev]

Thanks for the suggestions!

I quickly figured I had a different use-case and updated the questions. I left the original question in at the bottom.

The use-case is with compiled files.

[wongjn]

Consider using a unique prefix per each plugin. This will ensure class names for that plugin would only be applied to its own code. Though this does mean you will get some duplicate rules, but differentiated by the prefix.

[adrianthedev]

Yup. Though of that. It becomes teadious really fast... I would much prefer to use the same ones that everyone is used to.
Thanks!

[amanabate]

You can avoid CSS conflicts in Avo and its plugins by namespacing each plugin’s Tailwind CSS and shipping it precompiled:

1.Prefix classes in tailwind.config.js for each plugin:
module.exports = { prefix: 'plugin1-', content: ['./app/views/**/*.html.erb'], theme: { extend: {} } }

2.Precompile CSS in the plugin repo so users don’t need to run Tailwind:
npx tailwindcss -i ./src/styles.css -o ./dist/plugin1.css --minify

3.Include the CSS in the Rails app:
<%= stylesheet_link_tag 'avo', 'plugin1', media: 'all' %>

[wongjn]

Bear in mind the code shown here is for v3.