[WIP] Added tailwind:plugin command

[jaxwilko]

This is a POC for allowing plugin vendors to compile css patches used to include their required tailwind css as a seperate file.

The idea being users should not have to recompile the Winter.TailwindUI package to add addtional tailwind css rules for custom plugins, but instead should be able to use the plugin to compile an additional backend.css file specific for their plugin.

Usage:

The target plugin must implement a tailwind.config.js file, however this can be an import of the original. For example:

const config = require('../../winter/tailwindui/tailwind.config.js');

config.content.push('./controllers/example/assets/src/**/*.{vue,htm}');

module.exports = config;

Then run the following:

./artisan tailwind:plugin author.plugin
(I also added support for passing webpack args to mix:compile)
./artisan tailwind:plugin author.plugin -- --stats-children

And a file will be created: author/plugin/assets/dist/css/backend.css which will only include the additional tailwind css rules added by their config extension.

Improvements:

This POC is implmented using some file hackery, it would be better to extend our mix support so we can inject custom mix configurations, allowing us to configure the tailwind config path. I attempted to do this using the postcss.config.js approach but it didn't seem to work properly.

If we did add the above override we could also dynamically rewrite output instructions, allowing us to not have to move the tailwindui plugin's backend.css file around.

Adding support for watch would also be very nice.

Any thoughts very welcome :)

[bennothommo]

@jaxwilko I'm pretty sure we do have the ability to set a custom Tailwind config path in the Mix commands.

I'm curious as to what overrides would be needed? Given that the Tailwind config could (mostly) be configured with JSON, we could allow it, but it might not be easy if we want to do dynamic stuff like importing / extending defaults and the like.

[LukeTowers]

@bennothommo the point of the override use case isn't to actually override any of the base styles provided by this plugin, it's moreso to make other plugins play nicer with the default config provided by this plugin in its compiled styles; i.e. to make other plugins more aware of font choices, colours, breakpoints, etc introduced by this plugin.

[LukeTowers]

You can use the \System\Console\Traits\HasPluginArgument to add automatic support for autocompletion, validation, and resolution of the plugin argument.

[LukeTowers]

Can you add a unit test for this?

[jaxwilko]

Can you add a unit test for this?

There are many things that need to be added, but yeah unit tests would be good :)

[jaxwilko]

@bennothommo I wasn't really talking about the tailwind config but more the mix config that is generated from the fixture during the compile. If we had the ability to dynamically extend that in php then we could avoid having to do all the horrible file moving and switching :)

[bennothommo]

@jaxwilko I'm a bit worried that, in that case, it might be too low level and open to abuse to be modifiable from the PHP side.

[bennothommo]

Could such customisations be driven from the JS side with a custom webpack config? I know Mix supports that at least.

[joseph-sm]

The artisan command would not register for me, I had to remove the line from the boot method and add the following method in Plugin.php:

public function register()
    {
        $this->registerConsoleCommand('tailwindui.plugin', TailwindPlugin::class);
    }

[LukeTowers]

Workable solution for now until this works well: https://github.com/wintercms/wn-tailwindui-plugin/blob/main/README.md#using-tailwind-in-other-plugins