leptos-rs / cargo-leptos

Build tool for Leptos (Rust)
MIT License
328 stars 96 forks source link

`watch` ignores Rust's build system dependency tracking #187

Open myFavShrimp opened 11 months ago

myFavShrimp commented 11 months ago

When making changes to files included using the include_bytes! macro, such as include_bytes!("track.me"), changes to the track.me file do not trigger recompilation when using cargo leptos watch.

Using a build.rs with the contents

fn main() {
    println!("cargo:rerun-if-changed=src/**/*.me");
}

doesn't trigger recompilation either.

Baptistemontan commented 10 months ago

For my crate leptos_i18n I also need to track so files outside the default tracking directories of leptos watch, so I made a PR to add external files to the watch list: #191

Maybe this could help!

gbj commented 8 months ago

True! cargo-leptos does its own file watching to trigger rebuilds, which is not the same. It is not likely that I will have time to work on this in the near future, but a PR bringing it into accordance with the expected behavior would be welcome.

benwis commented 6 months ago

With #191 merged, I'm closing this. Feel free to comment if this isn't resolved

myFavShrimp commented 5 months ago

This is still a problem. The original issue is that the current implementation of watch does not respect files that are dynamically added to the build system's dependency tracking. Libraries may depend on this to trigger recompilation when specific files change.

Fixing this will also help supporting the path tracking api.

gbj commented 5 months ago

@myFavShrimp I'll reopen this because the change in #191 is a workaround, not the root issue, although it certainly seems capable of handling the case you originally listed.

To be honest, it's unlikely that any of us will have time to look at the refactoring needed to use Rust's build system rather than the custom file watching here. Would you like to look into it and consider making a PR?

Baptistemontan commented 5 months ago

I've made #191 originally for my crate leptos_i18n, and I've explored the tracking API linked by @myFavShrimp and it's a really good ressource, so I've implemented it for nightly and did some tests. the unstable API works but if I track the files in the macro without adding the files as dependencies for cargo leptos the problem still remains, there is no rebuild done. I don't know how cargo-leptos can go around this problem and track proc macro dependencies, this should be done by the maintainers of those macros.

What I don't understand is how include_bytes! fails to register the file as a dependencies, because it is the workaround for stable, if you have external files you can generate const _: &'static [u8] = include_bytes!("file/path.ext") to include the file (still some concerns about build time performances), so the include_bytes! macro should work.

PR for the implementation: https://github.com/Baptistemontan/leptos_i18n/pull/93

myFavShrimp commented 5 months ago

I can work on this when I have a clearer picture of what actually should be done.

I took a quick look at what trunk and cargo-watch do. Both seem to simply watch the project directory for changes and trigger a rebuild when something changes. Cargo's build process then takes the tracked files into account and determines whether the project has to be rebuild or not. Trunk offers the option to configure additional paths to watch and ignore.

Is this behavior desired for cargo-leptos?

Baptistemontan commented 5 months ago

@myFavShrimp

Is this behavior desired for cargo-leptos?

What behavior are you referencing? The option trunk offer for additional paths to watch? This is what I implemented with #191

myFavShrimp commented 5 months ago

Sorry I should have been clearer.

I did a quick test to see what similar tools do to achieve rebuilds when tracked files change (specifically trunk and cargo-watch). None of them seem to interact with Rust's build system directly. They just watch the whole project directory for changes and trigger a regular build when a file changes. Cargo's build process then takes the tracked files into account and determines whether the project has to be rebuild or not.

This is what I implemented with #191

This is indeed similar to what you have implemented but the key difference is that all files are being watched by default and there is the option to configure an ignore list.

I could not find any other way to achieve rebuilds when tracked files change.

Is this behavior desired for cargo-leptos?

What I mean by this question: Is it okay to change the file watching behavior of cargo-leptos to observe all files?

benwis commented 5 months ago

Sorry I should have been clearer.

I did a quick test to see what similar tools do to achieve rebuilds when tracked files change (specifically trunk and cargo-watch). None of them seem to interact with Rust's build system directly. They just watch the whole project directory for changes and trigger a regular build when a file changes. Cargo's build process then takes the tracked files into account and determines whether the project has to be rebuild or not.

This is what I implemented with #191

This is indeed similar to what you have implemented but the key difference is that all files are being watched by default and there is the option to configure an ignore list.

I could not find any other way to achieve rebuilds when tracked files change.

Is this behavior desired for cargo-leptos?

What I mean by this question: Is it okay to change the file watching behavior of cargo-leptos to observe all files?

All files? Like CSS, images, fonts, etc. etc.?

myFavShrimp commented 5 months ago

There are two exceptions. .git and .DS_Store are ignored by default for trunk. I haven't looked at cargo-watch's code.

luxalpa commented 1 month ago

I just want to report that I have a possibly related issue: When I watch a sub-project (examples/my-test-app) that's part of the workspace, it won't track source files in the parent workspace even though the main crate is set as a path dependency. Confusingly, it did seem to work with dependencies that are in a completely different folder.