Wow! Thanks so much @pklaschka and @kerrishotts for the responses. I’ve played with some stuff a bit more and I’ll share what I found.
Although this case was for a Photoshop plugin, I am trying to nail a workflow that will be applicable for both Photoshop and Xd plugin development. It’s worth noting that I’m not using the UXP cli (if there’s any resources or an npm package to use this, that would be great, maybe I missed it, but I’d love to play with it).
To clarify my workflow a bit, I’ve been running
yarn watch with my UXP projects directly inside the WSL root.
For example, storing my build directories in:
or (Windows equivalent)
yarn watch and enabling the watcher in UXP, I can make changes (have the project rebuild with those changes) and still not have the changes reflected in the UXP plugin. The only way around this (that I’ve found works) would be to manually reload the plugin from the UXP developer tool.
As I mentioned before, I feel like this is something to do with networking between WSL-level tasks and the UXP client running in native Windows but I’m unsure.
This workflow is different from what I did originally - which was just to keep my projects in my Windows drive:
I’ve just tested this again and moving my project out of the WSL root does work and trigger the watcher. However, it seems the file I/O in WSL is understandably less efficient, since building my project takes almost twice as long using commands in zsh or bash.
Thanks a lot @pklaschka for your hacky workaround with powershell. I figured that since I could use
explorer.exe and other windows processes in WSL there would be something I could do that I wasn’t aware of. At the moment, this works great, as it drastically increases my build speeds and lets me work within my preferred shell.