Symlinks not watched on OS X about karma-browserify HOT 24 CLOSED

Glad to hear it! Mind creating a minimal repo that reproduces this so that we can dig in more easily?

from karma-browserify.

You can basically just pop your karma file, your source file, test file, and set up the symlinks as you have them. Go ahead and commit node_modules with the symlink as you have it set up so I can clone and see exactly what you're seeing.

from karma-browserify.

@bendrucker thanks for the quick response. here's the repo:

https://github.com/scamden/karma-browserify-issue

to run tests: gulp karma-watch

from karma-browserify.

you'll have to install gulp globally if you haven't already npm install -g gulp

from karma-browserify.

and phantom but i assumed you have that from the karma.conf you posted. thanks for that btw :) helpful example

from karma-browserify.

I cannot reproduce your the problems you are reporting on Linux. This might be a MacOS issue related to file watching through symlinks. Could you check whether the issue can be solved by removing the symlinks?

You can also get more debug output by specifying:

    // see what is going on
    logLevel: 'LOG_DEBUG',

in your karma configuration.

@bendrucker you know a library that does a symlink like job as a browserify transform?

from karma-browserify.

Yup this is on OS X only. It's definitely due to symlinks. Added some changes to the repo to actually verify the right behavior (most importantly: only including the spec file in the bundle). A file required via a normal relative require works normally and gets watched. The symlinked file does not.

bendrucker/karma-browserify-issue@5bc844c

So the reason I don't do this in my projects is:

1. With the symlink strategy, you have to commit your node_modules or the tests break. I don't care about Windows but I do choose to omit my modules from source control and Travis needs to run tests. Running a script that hooks up the links in CI is just one more thing to do.
2. The transform way (don't happen to know a specific solution) makes your code browserify only. The idea of running the code or tests itself in Node during dev is out of the window.

Not sure that paulmillr/chokidar#31 is actually related here since you're trying to watch a file accessible through a link rather than the link itself. If I have time this weekend I'll play with attaching some watchify handlers and seeing if I can figure anything out.

from karma-browserify.

Spoke too soon on paulmillr/chokidar#31. That's it. Chokidars watchers don't fire on symlinks. Replacing file with fs.realpathSync(file) at https://github.com/substack/watchify/blob/master/index.js#L83 provides the expected behavior.

Unfortunately there's not much to be done about this since it's really chokidar's responsibility to handle this. I'll keep an eye on the issue over there.

from karma-browserify.

alright thanks for all your help! i'll keep an eye on that issue

On 14 November 2014 10:04, Ben Drucker [email protected] wrote:

Spoke too soon on paulmillr/chokidar#31
paulmillr/chokidar#31. That's it. Chokidars
watchers don't fire on symlink. Replacing file with fs.realpathSync(file)
at https://github.com/substack/watchify/blob/master/index.js#L83 provides
the expected behavior.

Unfortunately there's not much to be done about this since it's really
chokidar's responsibility to handle this. I'll keep an eye on the issue
over there.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.

Frustrating as it may be, I'd advise using normal relative paths until that issue shakes out. I think people worry all too much about trying to have nice paths. It's definitely nice to be able to move around your directories and change one thing instead of every reference. IMO it's also not worth a bunch of up front hassle over a minor inconvenience down the road.

from karma-browserify.

Ya I started using the symlink solution on a different project that wasn't
originally commonjs patterm and had a very nested folder structure, but
this one is almost entirely flat so I'll probably take your advice there.
Thanks again for looking into it!

On 14 November 2014 10:36, Ben Drucker [email protected] wrote:

Frustrating as it may be, I'd advise using normal relative paths until
that issue shakes out. I think people worry all too much about trying to
have nice paths. It's definitely nice to be able to move around your
directories and change one thing instead of every reference. IMO it's also
not worth a bunch of up front hassle over a minor inconvenience down the
road.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.

And I agree the cost of doing the symlinks has already well out weighed the
cost of a (possible but unlikely) refactor down the road.

On 14 November 2014 14:22, Sterling Camden [email protected] wrote:

Ya I started using the symlink solution on a different project that wasn't
originally commonjs patterm and had a very nested folder structure, but
this one is almost entirely flat so I'll probably take your advice there.
Thanks again for looking into it!

On 14 November 2014 10:36, Ben Drucker [email protected] wrote:

Frustrating as it may be, I'd advise using normal relative paths until
that issue shakes out. I think people worry all too much about trying to
have nice paths. It's definitely nice to be able to move around your
directories and change one thing instead of every reference. IMO it's also
not worth a bunch of up front hassle over a minor inconvenience down the
road.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.

@bendrucker latest chokidar seems to fix! https://github.com/scamden/karma-browserify-issue (new version checked in in node_modules)

from karma-browserify.

Awesome! If we need to update a dep when everything downstream gets released feel free to open an issue.

from karma-browserify.

for sure! would you want a pr for something that basic or just notify you?

On 4 December 2014 at 17:08, Ben Drucker [email protected] wrote:

Awesome! If we need to update a dep when everything downstream gets
released feel free to open an issue.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.

PR would be great. We have watchify set to accept all versions >= 2.11 < 3 so it should be automatic unless it sneaks in with breaking changes.

from karma-browserify.

sweet! ya looks like it will get in. btw who's we? is there like a team
working on this stuff? or just an official group?

On 4 December 2014 at 17:35, Ben Drucker [email protected] wrote:

PR would be great. We have watchify set to accept all versions >= 2.11 < 3
so it should be automatic unless it sneaks in with breaking changes.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.

Me and Nikku. Nothing fancy here, just that the watchify dep is ^2.1.1 so only >= 3.0 would require a change.

from karma-browserify.

cool cool, i was just curious if some company was like sponsering your
work, i'm interested in how larger scale open source projects get
maintained, we're starting to look towards open sourcing some things
ourselves, so i'm just gathering info. appreciate you taking the time with
this stuff

On 5 December 2014 at 05:20, Ben Drucker [email protected] wrote:

Me and Nikku. Nothing fancy here, just that the watchify dep is ^2.1.1 so
only >= 3.0 would require a change.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.

The blood sweat and tears of a very small pocket of volunteers. If an offer's on the table, I'm more than amenable to selling out :)

from karma-browserify.

@bendrucker hey man, so they bumped watchify to 2.2.1 to get the chokidar change, any chance you could bump to that version?

from karma-browserify.

this is the current: "watchify": "~2.1.1"

from karma-browserify.

The latest watchify version broke our build. We need to migrate to browserify 7.x, too before we can do it.

from karma-browserify.

arg sorry to hear that, it works if installed locally, but i imagine you
have some tests failing or something, let me know if i can help at all

On 12 December 2014 at 15:46, Nico Rehwaldt [email protected]
wrote:

The latest watchify version broke our build. We need to migrate to
browserify 7.x, too before we can do it.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Sterling Camden
Software Engineer
502 Emerson Street | Palo Alto, CA 94301
303.520.2968 | [email protected]

from karma-browserify.