[BUG] The `watch` feature in 0.13.1 is now not working

[deities-online]

the watch feature in 0.13.1 is now not working. OS: MacOS BigSur

trunk watch trunk serve are not be notified while files under current dir has been modified.

Source Code Version:

commit 7eeaf9e3f67e43d4c17e147da32f9f8ec0254f25 (HEAD -> master, origin/master, origin/HEAD)
Author: Anthony Dodd <2380740+thedodd@users.noreply.github.com>
Date:   Wed Aug 11 21:54:47 2021 -0500

    Tweaks to the auto-reload feature (#227)

    This moves the injection of the auto-reload system to the HTML build
    pipeline. This greatly simplifies the injection of the code into the web
    app HTML and only needs to take place once per build.

[thedodd]

Hello there. Do you mind sharing your configuration setup. Depending on your configuration, the "current dir" may not be one of the dirs which Trunk even attempts to watch.

[teenjuna]

Hi! I have a similar setup and this happens to me too. I'm trying to serve the todomvc example from Yew. There is no Trunk.toml config file, so I'm not sure the issue is related to that. trunk config show gives me the following output:

ConfigOpts {
    build: Some(
        ConfigOptsBuild {
            target: None,
            release: false,
            dist: None,
            public_url: None,
        },
    ),
    watch: Some(
        ConfigOptsWatch {
            watch: None,
            ignore: None,
        },
    ),
    serve: Some(
        ConfigOptsServe {
            port: None,
            open: false,
            proxy_backend: None,
            proxy_rewrite: None,
            proxy_ws: false,
        },
    ),
    clean: Some(
        ConfigOptsClean {
            dist: None,
            cargo: false,
        },
    ),
    tools: None,
    proxy: None,
}

I've also tried this with trunk serve --watch ., but it didn't help.

[deities-online]

Hello there. Do you mind sharing your configuration setup. Depending on your configuration, the "current dir" may not be one of the dirs which Trunk even attempts to watch.

My trunk config show gives me the same output as @teenjuna 's, and I also tried to recompile trunk itself, also not work.

[lukechu10]

I've also tried this with trunk serve --watch ., but it didn't help.

The correct command should be simply trunk serve. Are you running this in the same working directory as the example? That is:

cd examples/todomvc
trunk serve

Also by default, trunk only watches files inside the current working directory, so changing yew source will not trigger a build.

[teenjuna]

Hi, @lukechu10! Yeah, my first attempt was to just run it with trunk serve inside the examples/todomvc directory. However, I didn't know that the watcher is not recursive. Now that I know it, I've tried running it with trunk serve -w src/, but the change of src/main.rs doesn't trigger rebuild. If I run it with trunk serve -w src/main.rs, it does. Is is the intended behaviour? Seems pretty counterintuitive and inconvenient. Also, is is possible to watch every *.rs file recursively? Something like -w src/**/*.rs.

[thedodd]

Trunk does watch recursively: https://github.com/thedodd/trunk/blob/v0.13.1/src/watch.rs#L141

So, this is interesting because if I checkout yewstack/yew on master, cd into examples/todomvc, and then execute trunk serve everything appears to be working exactly as expected. The app builds correctly, and when I make modifications to any of the files in that directory (barring the generated dist dir), Trunk detects the changes and rebuilds. I am also on MacOS BigSur.

@teenjuna Trunk.toml is optional, so that wouldn't impact the behavior here.

@deities-online && @teenjuna what are you using to make modifications to the files? Mind performing the following experiment for me:

• first, git commit or stash so that we don't blow away any of your work,
• then cd into examples/todomvc,
• execute trunk serve (nothing else, just that) from within examples/todomvc,
• from another shell, cd into examples/todomvc, then execute echo > src/main.rs to "directly" modify the file (no editor or anything)
• trunk should detect the changes and re-build.

Keep me posted on that experiment. I am trying to find out why things are behaving differently for you in this case.

[teenjuna]

@thedodd, a) I'm using neovim 0.5 as my editor; b) the experiment that you proposed indeed triggered a re-build.

Here is a demonstration:

https://user-images.githubusercontent.com/53595243/130813644-80f99c19-9413-43ff-af8a-405034892dd7.mov

[deities-online]

It seems to be caused by the editor(neovim).

trunk serve
touch src/main.rs

trunk re-build.

trunk serve
nvim src/main.rs
// modify the file

nothing happen.

trunk serve
code .
// modify src/main.rs

trunk re-build.

Note: my neovim version is same as @teenjuna 's.

[lukechu10]

Maybe this is related to #238 Seems like neovim does not trigger trunk whereas VSCode triggers trunk twice.

[teenjuna]

As a temporary solution one can run trunk with cargo-watch:

cargo watch -c -- trunk serve

Seems like cargo watch uses watchexec that uses notify 4.0.15 under the hood. If I understood #238 right, the problem might be indeed related to the new version of notify.

[teenjuna]

Here is the difference between filesystem events with neovim and cat > ...:

neovim:

❯ fswatch -x .
~/Dev/yew/examples/todomvc/src/4913 OwnerModified Created IsFile Removed
~/Dev/yew/examples/todomvc/src/main.rs OwnerModified Created IsFile Updated Renamed
~/Dev/yew/examples/todomvc/src/main.rs OwnerModified Created IsFile Updated
~/Dev/yew/examples/todomvc/src/main.rs~ IsFile Removed Renamed

cat:

❯ fswatch -x .
~/Dev/yew/examples/todomvc/src/main.rs AttributeModified IsFile Updated

[jryio]

@thedodd I am experiencing this bug as well with neovim and trunk serve --watch. Trunk would rebuild after I modified my assets (html,css, scss) but not with rust files.

@teenjuna is correct cargo watch -c -- trunk serve will properly pickup on fsevent changes via neovim and restart trunk.

[maxcountryman]

I'm running into this issue with neovim as well. However, what's odd is that in my case every now and then trunk does seem to notice a change and restarts as expected. This makes me wonder if there could be some kind of race happening here?

[irh]

@danielnehrig noted in #331 that the backupcopy option in neovim is worth looking at. Setting the option to no makes trunk serve work as expected for me (it was set to auto by default).

[JulianusIV]

Same issue here pretty much, trunk serve doesn't trigger a rebuild when files are changed, only when files or folders are created, deleted, moved, or renamed.

• OS: Win 11 Pro 22H2
  • Build: 22621.2428
• Editor: VSCode
  • Version: 1.83.1
• Trunk Version: 0.17.5

Hope this helps to resolve this, if you need more details feel free to ask

Edit: I have been going back a few versions and its seems that the last version of Trunk that this doesn't occur in is 0.17.3

[jannisbecker]

@JulianusIV I can confirm the same behavior on the exact same system. Downgrading trunk 0.17.3 indeed fixed it, thank you for mentioning the workaround!

[xobs]

I noticed on Windows that watch events were frequently reported as ModifyKind::Any which basically means "The notify system couldn't tell what it was" or "It's a type of event that the notify system doesn't know about yet".

I created a patch that adds this as an acceptable type. It fixes watching for me on Windows, and I would be interested to see if it improves things on other platforms.

[xobs]

The PR is https://github.com/thedodd/trunk/pull/620

[ctron]

I think it's worth mentioning there had been a number of fixes on trunk-ng. I would encourage you to try this out: https://github.com/ctron/trunk … If it's still an issue, let me know.

[drmason13]

I think it's worth mentioning there had been a number of fixes on trunk-ng. I would encourage you to try this out: https://github.com/ctron/trunk … If it's still an issue, let me know.

I encountered the same problem on windows with vscode, and switching to trunk-ng solved the problem for me. Thank you ctron :)

[wxyer]

@JulianusIV I can confirm the same behavior on the exact same system. Downgrading trunk 0.17.3 indeed fixed it, thank you for mentioning the workaround!

i tested it with your solution,it's correct!

[ctron]

This fix got merged to trunk now too. It should be part of the next trunk release.

[ctron]

Released with trunk 0.18.0