Open hpx7 opened 2 years ago
Hi @hpx7! Sorry for the delay; I was pretty swamped this week.
I'm on it! I've always wanted to figure out how to develop/test for Windows. I'll try to track it down and let you know what I find!
From the bit of code you linked to, I'm guessing that you're supporting TypeScript for your users by way of ts-node
. Hopefully, hot-esm
is playing nice with that loader. Let me know if you find any weird interactions.
Thanks @vinsonchuong! You can try getting a Windows VM on Azure for testing purposes.
Yup the loaders are working great with each other, although it was a pain to set up initially.
Hey @vinsonchuong have you had a chance to look into this at all?
@hpx7 Apologies for the delay. Work has been occupying me more than I'd like...
I have been looking into this whenever I can find the time.
It took forever to figure out how to do performant virtualization of Windows 11. I figured it out though. I foresee that I'll probably be spending more time writing code in the Windows VM as I find issues in my packages.
I do have failing unit tests for hot-esm
in Windows, both in the PowerShell and WSL.
My plan is to first build support for the WSL as that seems like it will take the least work.
Then, I'll see how to make it all run in a regular PowerShell. I suspect that I may have to add Windows support to some of my other packages to hit this goal...
@hpx7, do you insights into how you or your Windows users like to run Node.js code? Whether WSL is popular, or Cygwin, or MinGW? I'm a bit out of touch with development on Windows these days.
Glad to hear that you were able to get a repro!
I believe most users are using WSL
@hpx7, I've gotten some learnings.
I'm currently using ArchWSL instead of Ubuntu, mainly just to be able to easily get the latest versions of different packages. But, I don't think this should cause differences in behavior.
hot-esm
seems to work fine as long as the code is inside of the Linux file system, e.g. /root/project
. It definitely does not work when the code is in C:\
, e.g. /mnt/c/Users/vinson/project
.
I traced it to this issue against WSL. Because of this, Chokidar is unable to efficiently watch for file updates using inotify
. I can recover the functionality by telling Chokidar to poll instead. I'm not sure what the performance implications are though.
I could probably come up with a way to detect the kind of file system and switch to polling only when necessary.
Hey @vinsonchuong, wanted to check in and see if you've had time to investigate this any further?
Hey @hpx7, sorry for dropping the loop on this.
For Windows users, if their codebase is located in the "native" Linux file system, file watching should work. (Let me know if that's not what you're seeing). I'd suggest doing this if possible.
But, if it's elsewhere, like on the C:\
drive, our only recourse is to poll each file that we want to watch. I have no idea what the performance would look like, or how it would change as the size of a codebase grows though. So, I've been hesitant to pull the trigger on this.
I've figured out how to get metadata on the file system, so, I could automatically switch to polling if I know inotify isn't going to work.
I could also instead allow an environment variable to be set to force polling.
Do you have thoughts on which one you'd like to see?
@vinsonchuong there are indeed users with projects on the C:\
drive who are running into this issue. I think the automatic switch to polling would be best. I'm not too concerned about performance, but I can provide timely feedback via my users on how well a solution works for them.
@hpx7, I've released a fix in version 1.5.0
.
In WSL, when watching files that live in 9P mounts, like C:\
, we automatically switch to polling. I've only tested this in Windows 11 so far.
Let me know if you notice anything amiss.
Hi again!
Wanted to bring to your attention that I think hot-esm doesn't work on Windows. I recently disabled hot-esm in my project because it was causing issues.
I think it has something to do with paths on windows but I didn't get a chance to look into it too much -- just raising it to you in case you have some time to look into it!