Skip to content
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

Closed
phillipbaird opened this issue Jan 26, 2023 · 5 comments · Fixed by #65
Closed

Changes by Tailwind not being actioned. #62

phillipbaird opened this issue Jan 26, 2023 · 5 comments · Fixed by #65

Comments

@phillipbaird
Copy link
Contributor

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

  1. Tailwind is started with tailwindcss -w -i ./tailwind.css -o ./css/main.css
  2. cargo-leptos is started with cargo leptos watch
  3. Open a browser to localhost:3000.
  4. Edit file app/src/lib.rs to change a color, e.g. bg-green-300 is changed to bg-blue-300.

What I expected...

  • cargo-leptos observes the change in app/src/lib.rs and rebuilds the front end and server.
  • Tailwind observes the change and adds bg-blue-300 to css/main.css.
  • cargo-leptos observes the change in css/main.css and redeploys the file to target/site/pkg.
  • cargo-leptos notifies the browser of the changes so it can auto reload the changes.

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...

listening on 127.0.0.1:3000
      Reload websocket connected
      Notify not handled NoticeWrite("/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/app/src/lib.rs")
      Notify not handled NoticeWrite("/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/css/main.css")
      Notify handle Some("app/src/lib.rs")
      Notify lib source change write "app/src/lib.rs"
      Notify bin source change write "app/src/lib.rs"
   Interrupt send done
          FS create_dir_all "target/site/pkg"
      Assets finished (no changes)
       Style no build needed ChangeSet([LibSource, BinSource])
      Notify handle Some("css/main.css")
      Notify style change write "css/main.css"
   Interrupt send done
       Cargo process interrupted
       Cargo process interrupted
       Build step done with no changes
   Interrupt source changed cleared
       Watch waiting for changes
       Front no changes to rebuild
      Assets finished (no changes)
       Style no build needed ChangeSet([])
       Build step done with no changes
   Interrupt source changed cleared
       Watch waiting for changes

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 the app/src/lib.rs file, everything appears to work correctly. The log produced looks like this...

listening on 127.0.0.1:3000
      Reload websocket connected
      Notify not handled NoticeWrite("/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/app/src/lib.rs")
      Notify handle Some("app/src/lib.rs")
      Notify lib source change write "app/src/lib.rs"
      Notify bin source change write "app/src/lib.rs"
   Interrupt send done
          FS create_dir_all "target/site/pkg"
      Assets finished (no changes)
       Style no build needed ChangeSet([LibSource, BinSource])
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on package cache
    Blocking waiting for file lock on package cache
   Compiling app-package v0.1.0 (/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/app)
   Compiling app-package v0.1.0 (/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/app)
   Compiling front-package v0.1.0 (/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/front)
   Compiling server-package v0.1.0 (/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/server)
    Finished dev [unoptimized + debuginfo] target(s) in 0.85s
       Cargo process finished with success
       Cargo envs: LEPTOS_OUTPUT_NAME=project LEPTOS_SITE_ROOT=target/site LEPTOS_SITE_PKG_DIR=pkg LEPTOS_SITE_ADDR=127.0.0.1:3000 LEPTOS_RELOAD_PORT=3001 LEPTOS_LIB_DIR=front LEPTOS_BIN_DIR=server LEPTOS_WATCH=ON
       Cargo finished cargo build --package=front-package --lib --target-dir=target/front --target=wasm32-unknown-unknown --no-default-features
       Front wrote wasm to "target/site/pkg/project.wasm"
          FS create_dir_all "target/site/pkg"
       Front js changed
       Front wasm changed
    Finished dev [unoptimized + debuginfo] target(s) in 1.60s
       Cargo process finished with success
       Cargo envs: LEPTOS_OUTPUT_NAME=project LEPTOS_SITE_ROOT=target/site LEPTOS_SITE_PKG_DIR=pkg LEPTOS_SITE_ADDR=127.0.0.1:3000 LEPTOS_RELOAD_PORT=3001 LEPTOS_LIB_DIR=front LEPTOS_BIN_DIR=server LEPTOS_WATCH=ON
       Cargo finished cargo build --package=server-package --bin=server-package --target-dir=target/server --no-default-features
        Site update hash for target/server/debug/server-package to 10101298684753574922
       Cargo server bin changed
       Build step done with changes: Server, Front
      Server restart sent
       Watch updated Server, Front. Server restarting
   Interrupt source changed cleared
       Watch waiting for changes
       Serve stopped
       Serve running target/server/debug/server-package
       Serve restarted
listening on 127.0.0.1:3000
      Reload server port 127.0.0.1:3000 open
      Reload sent "reload all" to browser
      Reload websocket closed
      Reload websocket connected
      Notify not handled NoticeWrite("/home/phillipb/Repositories/leptos-experiments/leptos-axum-start/css/main.css")
      Notify handle Some("css/main.css")
      Notify style change write "css/main.css"
   Interrupt send done
       Front no changes to rebuild
      Assets finished (no changes)
          FS create_dir_all "target/site/pkg"
       Style found: css/main.css -> @pkg/project.css
          FS create_dir_all "target/site/pkg"
       Style finished with changes css/main.css -> @pkg/project.css
       Build step done with changes: Style
       Watch updated style
   Interrupt source changed cleared
       Watch waiting for changes
      Reload server port 127.0.0.1:3000 open
      Reload sent "reload pkg/project.css" to browser 

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 and bg-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.

@ManitVig
Copy link
Contributor

ManitVig commented Jan 26, 2023

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 cargo leptos detected the changes to the css file made by tailwind and tries to update the server. This is the output I got:-

Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Notify handle Some("style/bin.css") Notify style change write "style/bin.css" Interrupt send done Cargo process interrupted Cargo process interrupted Build step done with no changes Interrupt source changed cleared Watch waiting for changes Front no changes to rebuild Assets finished (no changes) Style no build needed ChangeSet([]) Build step done with no changes Interrupt source changed cleared Watch waiting for changes Notify not handled NoticeWrite("/Users/manitvig/Documents/codeworks/rust/first-leptos-project/src/app.rs") Notify handle Some("src/app.rs") Notify lib source change write "src/app.rs" Notify bin source change write "src/app.rs" Interrupt send done FS create_dir_all "target/site/pkg" Assets finished (no changes) Style no build needed ChangeSet([LibSource, BinSource]) Notify not handled NoticeWrite("/Users/manitvig/Documents/codeworks/rust/first-leptos-project/style/bin.css") Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Blocking waiting for file lock on package cache Notify handle Some("style/bin.css") Notify style change write "style/bin.css" Interrupt send done Cargo process interrupted Cargo process interrupted Build step done with no changes Interrupt source changed cleared Watch waiting for changes Front no changes to rebuild Assets finished (no changes) Style no build needed ChangeSet([]) Build step done with no changes Interrupt source changed cleared Watch waiting for changes

But the changes were not reflected on the browser. Only when I stopped the cargo leptos watch process and restarted the changes were reflected on the browser probably since the classes were now cached in the output css file.

I am thinking of adding first class support for tailwind in leptos as it seems the best way to solve this issue.
You can refer to this: #18 if you want to see progress.

phillipbaird added a commit to phillipbaird/cargo-leptos that referenced this issue Jan 27, 2023
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.
@phillipbaird
Copy link
Contributor Author

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.

@ManitVig
Copy link
Contributor

ManitVig commented Jan 27, 2023

@phillipbaird Do you mind merging your fork into my tailwind-support branch here: #63
I think after your changes all I'll have to do in order to have first-class tailwind support working is to either spawn a new thread running tailwind watch using tokio::spawn before run_loop starts executing if the tailwind parameter of project config is true, or call tailwind build if in watch.rs set contains Product::Front

@akesson Do you think any of those methods might work?

@phillipbaird
Copy link
Contributor Author

@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.

@akesson
Copy link
Collaborator

akesson commented Jan 27, 2023

@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 main branch?

@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?

akesson pushed a commit that referenced this issue Jan 27, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants