Does the UXP developer tool support development from WSL?

UXP Developer Tool
1

Hey! For the past couple days of using the UXP developer tool, I have been managing projects using my WSL instance. My projects load into the UXP tool fine, however all hot reload/watch mechanics of the UXP tool do not work.

After further reading, I recognized that UXP triggers watch/reload with websockets and was curious as to whether this may be impeding development from a WSL instance.

Could this be the blocker for using the ‘Watch’ feature on WSL? Is there a particular workflow people on WSL machines use?

Any insight, knowledge, or help would be appreciated! Thanks!

1 Like
2

Can you clarify what you mean by “WSL”?

1 Like
3

Of course! WSL (Windows Subsystem for Linux) is just a compatability layer that can be activated within windows to integrate a Linux distribution with UNIX-like commands into Windows environment. As a result, I believe the Linux layer I’m working on in Windows runs on a different network layer than UXP (which is why the websockets aren’t being triggered as changes are made).

Still curious if anyone here has any workarounds, although, after some more research, I’m assuming this is more an issue on the side of networking/windows, and nothing that can be done on the end of UXP.

1 Like
4

Would be good to know more about how you’re doing the build process and the like. I’m making an assumption that you’re running npm watch and the like via WSL, and that the files are in WSL’s filesystem. Can you clarify your workflow a bit more?

2 Likes
5

To clarify: @jake-pauls, I’m assuming it’s the CLI version you’re running within the WSL environment? Are you currently developing plugins for XD, Photoshop, or both?

@kerrishotts I already took a look at the Dev Tools sources while PS plugins were still in the prerelease stage (I’m not sure how outdated my knowledge, therefore, is). Since I do, however, have prior experience with developing plugins within the WSL, adjusted (while a lot easier, of course) xdpm to work with it (cf. Support for Windows Subsystem for Linux by pklaschka · Pull Request #21 · AdobeXD/xdpm · GitHub), and have at least some familiarity with how the dev tools approximately work, I might be able to look into what the scope of supporting the WSL in it would be :thinking:

@jake-pauls: As an idea for a work-around: I haven’t tested it myself, but if I’m not mistaken, the path within both the WSL and other terminals are usually “compatible”. This means that you can run powershell.exe from the WSL. With -C, you can specify a command to run by the PowerShell:

image

While it is a really ugly hack, it could probably allow you to run the commands (or npm scripts, if they are adjusted to match this) from the WSL (meaning you at least don’t have to change the terminal), with the only prerequisite being to have the dev tools installed on the “Windows instance” of npm…

1 Like
6

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:

~/projects/ps-plugin/dist/manifest.json

or (Windows equivalent)

\\wsl$\Distro\home\USER\projects\ps-plugin\dist\manifest.json

After running 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:

/mnt/c/WINDOWS/system32/project/...

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.