-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes by Tailwind not being actioned. #62
Comments
I am facing a similar issue. I tried using tailwind the same way you did in watch mode and everytime I used a new utility class that wasn't used before
But the changes were not reflected on the browser. Only when I stopped the I am thinking of adding first class support for tailwind in leptos as it seems the best way to solve this issue. |
Fixes leptos-rs#62. When multiple file system updates occur close together in time, the first change (.rs file) may start a build process and the second (Tailwind css) may interrupt the build. The run_loop function was not checking if the builds were interrupted and would clear the list of file changes. With the notification of the first file change now gone the rebuild process would not complete correctly. This change prevents the change list from being cleared if the builds have been interrupted by additional file system updates.
Have found the problem. When we change a .rs file this triggers cargo-leptos to start a build process. Tailwind then sees the same change and rebuilds the .css file. cargo-leptos responds to the .css file change and stops the current build. The problem is the run_loop() in command/watch.rs does not recognize the interruption and it clears out the change list. This prevents the next iteration of the loop from completing correctly as it no longer knows the .rs file changed and so the required rebuilds do not occur. I have implemented a fix which changes run_loop() so that it checks the outcomes of the build processes to see if any have been stopped. If any were stopped then the loop just iterates without clearing the change list. This restarts the build process and the build completes and deploys successfully. This fix can be reviewed in my fork here: phillipbaird@8a8922d @akesson Any chance you could take a look and let me know if you'd be open to a pull request? Thanks. |
@phillipbaird Do you mind merging your fork into my @akesson Do you think any of those methods might work? |
@ManitVig My reservation with your request is that the change I've made is not specific to Tailwind support. Its a more general problem of the change list getting cleared when builds are stopped. Tailwind demonstrates the problem but any file system update could probably trigger similar problems. I'd like to give @akesson time to review this before progressing any further. |
@phillipbaird Thanks! Really nice catch. I suspected something like that but just don't have time to investigate it. Could you raise a PR for merging it to @ManitVig please keep comments related to the tailwind integration in the ticket created for tracking it. Could you transfer the above tailwind support discussion to there and I'll reply there instead? |
Fixes #62. When multiple file system updates occur close together in time, the first change (.rs file) may start a build process and the second (Tailwind css) may interrupt the build. The run_loop function was not checking if the builds were interrupted and would clear the list of file changes. With the notification of the first file change now gone the rebuild process would not complete correctly. This change prevents the change list from being cleared if the builds have been interrupted by additional file system updates.
Hi there,
Thank you for creating this cargo plug. I suspect there is an issue with it working with Tailwinds watch mode.
Background
TailwindCSS is a utility-first css framework. It reads the class names referenced in your source files and generates a css file for your site. Essentially its just a css file generator. You can run it in watch mode and each time you save a change to your source it updates your css file to match.
What I'm doing...
I've created a simple starter template for Leptos + Axum + Tailwind that can be found at https://github.com/phillipbaird/leptos-axum-start
tailwindcss -w -i ./tailwind.css -o ./css/main.css
cargo leptos watch
app/src/lib.rs
to change a color, e.g.bg-green-300
is changed tobg-blue-300
.What I expected...
app/src/lib.rs
and rebuilds the front end and server.bg-blue-300
tocss/main.css
.css/main.css
and redeploys the file totarget/site/pkg
.What actually happened...
It appears as though cargo-leptos is observing the changes but is not actioning them. Neither the Rust code was rebuilt nor was the css redeployed.
Using
cargo leptos watch -vv
produced the following log when the change was saved...If instead of running Tailwind in watch mode I run it manually (using
tailwindcss -i ./tailwind.css -o ./css/main.css
) after saving the edit to theapp/src/lib.rs
file, everything appears to work correctly. The log produced looks like this...Environment
cargo-leptos: 0.1.4
OS: Linux Arch 6.1.7
rustc: 1.68.0-nightly (52372f9c7 2023-01-21)
Tailwind CSS: 3.2.4 (binary cli from https://github.com/tailwindlabs/tailwindcss/releases)
Is anyone else able to reproduce this?
Testing Note
When testing this do not toggle back and forth between two colors, e.g.
bg-blue-300
andbg-green-300
. The reason for this is that when Tailwind is running in watch mode, it will only add classes to the generated .css file. If you toggle back and forth between two values the .css file may contain both colors so may not change. Either always use a new color or restart Tailwind and cargo-leptos before doing the test.The text was updated successfully, but these errors were encountered: