Open myFavShrimp opened 1 year 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!
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.
With #191 merged, I'm closing this. Feel free to comment if this isn't resolved
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.
@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?
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
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?
@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
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?
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.?
There are two exceptions. .git
and .DS_Store
are ignored by default for trunk. I haven't looked at cargo-watch's code.
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.
When making changes to files included using the
include_bytes!
macro, such asinclude_bytes!("track.me")
, changes to the track.me file do not trigger recompilation when usingcargo leptos watch
.Using a
build.rs
with the contentsdoesn't trigger recompilation either.