Allow working with multiple entrypoints #58
Conversation
…." when css file is provided as relative path to tailwind:build command
…tion to `tailwind:build` command
The mocked return value should use `realpath`
src/Command/TailwindBuildCommand.php
Outdated
| @@ -32,6 +33,7 @@ public function __construct( | |||
| protected function configure(): void | |||
| { | |||
| $this | |||
| ->addArgument('input', InputArgument::OPTIONAL, 'The input CSS file to compile') | |||
There was a problem hiding this comment.
Should we really care about specifying the input file on running the command? Why can't we just build both files (I mean, all the input CSS files listed in the input_css option)? It will simplify things, no need to remember to pass the argument. Because as I understand, if you miss this arg (which is optional) - only the first entry on the input_css will be built. I'm afraid it will lead to WTF moments. IMO we should build all input CSS files listed by default, though I'm not against of keeping that optional arg in case you want to build a specific input CSS file only.
And how about to be consistent and call this input_css to match the config option? Does it make sense to you?
There was a problem hiding this comment.
It is possible to build both files, but since the Tailwind binary doesn't natively support this, we will need a workaround:
- In default mode (without the
--watchflag), it would run the process sequentially for each input file (or possibly in parallel if feasible). - In watch mode (with the
--watchflag), we would need to spawn as many processes as there are input files. I'm not sure if this will be efficient in terms of memory usage. I'll look into potential improvements.
I also think we can keep input_css as the argument name. I initially used input because in the first implementation, I wanted to provide it as a flag. I'll rename it back to input_css.
There was a problem hiding this comment.
I see, then the current implementation should be good IMO to keep things simple. But if anyone have any ideas how to improve it even further - feel free to share
There was a problem hiding this comment.
Great, thanks for your feedback.
I'll maybe try to improve this in another PR.
…css` for consistency with config file
…o `string` as it's always passed
I would welcome it if this would finally being merged 🥇 |
|
@adeys Thank you for working on it! |
This PR proposes a fix for issues #45 and #46, addressing the need to pass multiple entrypoints as an array to the tailwind builder.
With this enhancement, users can now specify multiple entrypoints by providing an array of file paths. When building, the entrypoint name should be passed to the command. If omitted, it defaults to the first entrypoint specified in the configuration.
This change enables the following behavior:
bin/console tailwind:build assets/styles/custom.csswill build the provided CSS file.bin/console tailwind:buildwill buildassets/styles/index.css.Additionally, the default
tailwind.built.cssfile is no longer generated. Instead, each entrypoint is compiled to a file named based on the original entrypoint name. For example,index.built.cssforindex.cssandcustom.built.cssforcustom.css.For BC compatibility, the
input_cssstill accepts a string value and requires no changes from the developerFeedback and improvement ideas are welcomed. Thank you!