v1.1.0 breaks browserify API

[mantoni]

I'm listening for package events in browserify and I'm using pkg.__dirname as documented.
With the latest release of this package, the __dirname points to all sorts of things. Sometimes the parent directory of the entry point, sometimes a .js file and in other cases it's correct.

Downgrading this module in my node_modules tree make it work fine again.

[mattfysh]

Appears to have broken in caff2ba

the packageFilter is now getting triggered when loading as a file, previously this would only trigger for loading directories. the module-deps package gets confused by all the extra callbacks triggered, and will emit an incorrect pkg.__dirname in its 'package' event. I will shrinkwrap these updates out, but would like to add that even though I agree the many-small-modules-doing-one-thing-well architecture is the right way to go - this kind of highlights the need for a layer of integration testing of common composition of these modules (ie. browserify's makeup).

[mattfysh]

any thoughts on this one? or does this need to be fixed further upstream?

[ghost]

I'm working on some patches to resolve and module-deps that should address these issues.

[ghost]

I've fixed this bug in resolve 1.1.3 and the currently staged browserify 9.0.0 and added some test cases to the suite for package events. Now I'm just waiting for browserify/browser-resolve#56 Closing here since the issue in resolve itself is finished.

[mantoni]

Yes, I can confirm that it's working fine again, also with browserify 8.1.3.
Thanks!