-
Notifications
You must be signed in to change notification settings - Fork 100
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
__dirname points to wrong package causing 'package' event to be omitted #73
Comments
+1 Just debugged a similar scenario and came to the same conclusion (using versions 9.0.8 and 3.7.6 respectively). |
pmowrer
added a commit
to pmowrer/module-deps
that referenced
this issue
Apr 20, 2015
pmowrer
added a commit
to pmowrer/module-deps
that referenced
this issue
Apr 20, 2015
pmowrer
added a commit
to pmowrer/module-deps
that referenced
this issue
Apr 20, 2015
pmowrer
added a commit
to pmowrer/module-deps
that referenced
this issue
Apr 20, 2015
pmowrer
added a commit
to pmowrer/module-deps
that referenced
this issue
May 5, 2015
pmowrer
added a commit
to pmowrer/module-deps
that referenced
this issue
May 5, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using browserify 9.0.3 using module-deps 3.7.2 and my code listens on the bundle.on('package') event.
I noticed that the event is sometimes not triggered for some packages, although the package gets included properly.
It does not occur reliable even if the same code is executed twice, so it seems to be some sort of async race condition.
Example:
These events are fired:
I tracked the problem down to this line where the _self.emittedPkg object already contains 'package2', although the 'package' even was not yet emitted for this package.
Digging further I found that in the resolver function the following situation may occur:
So it seems that the packageFilter function is called by another callback before the resolver function executes for this package? Just guessing though, I was not able to track it down further.
It seems to be similar to #67 and maybe also connected to (browserify/resolve#69)
But it differs to both issues in the fact, that __dirname does not simply point to a wrong path in the package but to a complete wrong package.
The text was updated successfully, but these errors were encountered: