Skip to content
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

Issue when tracking 'Objective-C' files (.m .h) and viewing them in Xcode IDE #65

Open
VladimirAmiorkov opened this issue Jan 25, 2019 · 6 comments

Comments

@VladimirAmiorkov
Copy link

VladimirAmiorkov commented Jan 25, 2019

Hi,

Love the package but I am having an road block where I get constant watchers triggers in scenario where watching Objective-C files of extension .h and .m . The issue is that if those files are opened in the Xcode IDE and they are being opened (simple navigation between them) their "Last opened" attribute in the file system is changed. This is registered as a change were npm-watch is conceded and a watcher is triggered.

My question is is it possible to tell npm-watch to only watch the content of the files ? This way any "system" changes to that file will not cause a watcher to trigger. In my case what I am trying to achieve is, when a change to one of those (change in its content) files is detected, to trigger a watcher which uses bash to rebuild and iOS framework using xcodebuild. It works but the issue is if I am observing those files via Xcode which is the only iOS IDE when I switch between files in the view the watcher is being triggered multiple times which makes it useless. Any ideas ?

From my research the issue is caused by the "Last opened" attribute of the file in Mac OS. This is changed each time a file is viewed in Xcode and it looks like that is considered a "change" by the npm-watch, which might be true for many cases. Any ideas what can be done so that this can be avoided, I am open to making a contribution to this repo but I have not worked with it so some general guidance can be of great help.

@VladimirAmiorkov
Copy link
Author

Also it looks like Xcode has some very "strange" way of managing the viewed files. From my further research it looks like Xcode IDE is constantly deleting/moving files in and out of the file system to achieve its "File saving"

It looks like this is a complete nightmare when it comes to using a file watcher on the files opened in Xcode. I have opened a bug in the Xcode product and I am waiting for a response from them about this strange file saving mechanics and if it can be modified.

@M-Zuber M-Zuber added the bug label Feb 7, 2019
@M-Zuber
Copy link
Owner

M-Zuber commented Feb 7, 2019

The actual watching of files is all done by nodemon, so I am doubtful if there is anything we can do....

Unfortunately I don't have access to a Max so I can't test, but I will try and look into this and see what I come up with

@remy
Copy link

remy commented Feb 7, 2019

If you allow flags to be passed to nodemon, the giving it the --legacy flag (terrible name, sorry) might work around the issue.

@VladimirAmiorkov
Copy link
Author

Hi @M-Zuber ,

Thank you for responding to this issue. After many hours investigating what atualy happens to the files when they are viewed in Xcode on Mac I have came to the following conclusion:

  • The files that Xcode views are being moved in and out of memory constantly (meaning they are being deleted and returned)

This unfortunately is very tricking to workaround when you are implementing a file watcher over such files. What I did finally to resolve this is to use a different file watcher named chokidar. That file watcher is quite different than this one and it provides JS callback with information about what changes have happened, to what etc. In that information there is an event with normal values of modified, deleted etc. , in this case tho the event that comes in unknown. This is both good and bad, it is bad because I am still not sure what actually happens to the files but it is good because I can "filter" those changes and only run my watcher logic when real event occurs.

So I switched to chokidar and implemented a custom filtering of the changes based on the event that comes. It is not a great solution but it is one that works, for now.

@remy
Copy link

remy commented Feb 8, 2019

@VladimirAmiorkov the nodemon issue might have been fixed a matter of days ago through the release of chokidar@2.1.4. It's landing in nodemon right now thanks to this issue so it should be in nodemon@1.18.10 and won't have the triggering issues you were seeing (I think!).

@M-Zuber
Copy link
Owner

M-Zuber commented Jun 13, 2021

@VladimirAmiorkov can you confirm if you are still having this issue?

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

No branches or pull requests

3 participants