You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently switched from using django-tailwind to django-tailwind-cli in one of my projects because it doesn't require installation on my machine. I appreciate all the great work you've done on this project!
I was using this setup with DaisyUI v4 and Tailwind v3, which required me to use version 2.21.1 of this package. To enable DaisyUI support, I used the TAILWIND_CLI_SRC_REPO configuration to point to tailwind-cli-extra. Additionally, since I already had existing files from my django-tailwind setup, I configured the TAILWIND_CLI_CONFIG_FILE to point to one of those files.
However, I noticed that my custom configuration file was not being picked up correctly during the build process.
To identify the issue, I examined the code and discovered that the build command was not passing the custom config path to the CLI. Specifically, I found the problem in the way the build command was constructed.
v2.21.1 Changes
I suggest the following fixes here to address the issue:
def _get_build_cmd(*, minify: bool = True, watch: bool = False) -> list[str]:
build_cmd = [
str(utils.get_full_cli_path()),
+ "--config",+ str(utils.get_full_config_file_path()),
"--output",
str(utils.get_full_dist_css_path()),
]
if minify:
build_cmd.append("--minify")
if watch:
build_cmd.append("--watch")
if conf.get_tailwind_cli_src_css() is not None:
build_cmd.extend(
[
"--input",
str(utils.get_full_src_css_path()),
]
)
return build_cmd
v4.1.10 Changes
I also tried upgrading to the latest version of the package and ran into the same problem, where the custom config path was not being passed to the CLI. After examining the code, I discovered that the issue lies in the way the build command is constructed.
I would suggest making the following changes here to address this issue:
@property
def build_cmd(self) -> list[str]:
result = [
str(self.cli_path),
"--output",
str(self.dist_css),
"--minify",
]
+ if self.config_file:+ result.extend(["--config", str(self.config_file)])
if self.src_css:
result.extend(["--input", str(self.src_css)])
return result
If you're open to it, I have opened a PR #156 that could address this. It would be great if you could review and, if it looks good, merge it.
The text was updated successfully, but these errors were encountered:
udit-001
changed the title
Custom Config Path Not Picked Up in django-tailwind-cli Build
Custom Config Path Not Picked Up in django-tailwind-cli Build Command
Mar 19, 2025
Thanks for the ticket and the pull request. I am currently looking into it. I worked a bit on a solution for #152, which tries to solve this issue too. But in a different way.
Hi,
I recently switched from using
django-tailwind
todjango-tailwind-cli
in one of my projects because it doesn't require installation on my machine. I appreciate all the great work you've done on this project!I was using this setup with DaisyUI v4 and Tailwind v3, which required me to use version
2.21.1
of this package. To enable DaisyUI support, I used theTAILWIND_CLI_SRC_REPO
configuration to point totailwind-cli-extra
. Additionally, since I already had existing files from my django-tailwind setup, I configured theTAILWIND_CLI_CONFIG_FILE
to point to one of those files.However, I noticed that my custom configuration file was not being picked up correctly during the build process.
To identify the issue, I examined the code and discovered that the build command was not passing the custom config path to the CLI. Specifically, I found the problem in the way the build command was constructed.
v2.21.1 Changes
I suggest the following fixes here to address the issue:
v4.1.10 Changes
I also tried upgrading to the latest version of the package and ran into the same problem, where the custom config path was not being passed to the CLI. After examining the code, I discovered that the issue lies in the way the build command is constructed.
I would suggest making the following changes here to address this issue:
If you're open to it, I have opened a PR #156 that could address this. It would be great if you could review and, if it looks good, merge it.
The text was updated successfully, but these errors were encountered: