New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using node-dev in a shared folder in a virtualbox guest #87

Open
pepve opened this Issue Oct 20, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@pepve
Contributor

pepve commented Oct 20, 2014

I've recently started using vagrant (with virtualbox) for my development environment. I've set it up so that my node project directory is shared to the vm. I then run the project in the vm, and edit the files on my own system (the host). The problem is that the virtualbox shared folder doesn't (and won't) support file system events. So for edits that are done on the host system, node-dev doesn't work.

I created a solution to this problem. And I'd like to know if this functionality is something you would consider merging (but maybe in a different implementation).

It works like this: on the host system you run (in the project directory) node-dev --listen 0.0.0.0:45654, in the guest vm you run node-dev --remote 192.168.0.1:45654 server.js (where 192.168.0.1 is the IP address of you host system in the virtual network).

@pepve

This comment has been minimized.

Show comment
Hide comment
@pepve

pepve Feb 3, 2015

Contributor

@fgnass In a belated response to your comment here I've created a new approach to the problem. Please let me know what you think. If you're okay with this one I'll release version 1.0.0 of remote-filewatcher (the new dependency that does the bulk of the work) and submit a pull request.

Contributor

pepve commented Feb 3, 2015

@fgnass In a belated response to your comment here I've created a new approach to the problem. Please let me know what you think. If you're okay with this one I'll release version 1.0.0 of remote-filewatcher (the new dependency that does the bulk of the work) and submit a pull request.

@fgnass

This comment has been minimized.

Show comment
Hide comment
@fgnass

fgnass Feb 8, 2015

Owner

👍 Awesome! Can you make this a pull request?

Owner

fgnass commented Feb 8, 2015

👍 Awesome! Can you make this a pull request?

@fgnass

This comment has been minimized.

Show comment
Hide comment
@fgnass

fgnass Feb 14, 2015

Owner

I did some work on filewatcher yesterday and think the easiest way to support your use-case would be to pass {polling: true} to the filewatcher instance. According to the docs this should work on network filesystems too.

Owner

fgnass commented Feb 14, 2015

I did some work on filewatcher yesterday and think the easiest way to support your use-case would be to pass {polling: true} to the filewatcher instance. According to the docs this should work on network filesystems too.

@davejamesmiller

This comment has been minimized.

Show comment
Hide comment
@davejamesmiller

davejamesmiller Jul 26, 2015

I have the same issue. Is there any way to pass {polling: true} to the filewatcher instance? As far as I can tell from the code this is currently not possible? I'd like to be able to pass it in as a config option... Thanks!

davejamesmiller commented Jul 26, 2015

I have the same issue. Is there any way to pass {polling: true} to the filewatcher instance? As far as I can tell from the code this is currently not possible? I'd like to be able to pass it in as a config option... Thanks!

fgnass added a commit that referenced this issue Aug 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment