-
Notifications
You must be signed in to change notification settings - Fork 73
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
Drop usage of collections, it breaks globals #160
Comments
The specific issue is in this line: https://github.com/kriskowal/q-io/blob/v1/fs-mock.js#L7 |
This is a big problem for me as well. My specific issue is |
Just ran into an issue with |
PR welcome that relieves the dependency on collections. q-io@v2 depends on q@v2 and collections@v2, which does not have shims, but migration will not be practical for many applications. |
So - in reference to your last comment @kriskowal: 'q-io@v2 depends on q@v2 and collections@v2, which does not have shims' - why is q-io v2 not latest on npm? |
See montagejs/collections#185 (comment) update |
@nite It’s become evident that v2 of Q, Q-IO, and Collections are never going to be "latest". It’s my experience that making breaking changes, even with care, is not really a service to the community, so I’ve backed away from all of these endeavors. Version ^1 is ink. I continue to stand by the first line of my last comment: PR welcome to relieves the dependency on collections in the version 1 train. |
I should note that @Stuk and I are in the process of upreving collections by publishing individual collections (sans shims) in the npm |
I spent quite some time not understanding how I could get -1 from an Array.find call, until I realized q-io had messed up the Array prototype by including a really old version of collections with out of date shims. For example, there is a bug in collections so that Array.find behaves like indexOf (!) on collections 0.2.0, and there is also no check for whether the prototype already contains the added methods, hence my native Array prototype was overridden, with catastrophic results. If you cannot easily get rid of the collections behavior, can you at least bump up the version, 0.2.0 being ancient and all (5.1.2 is the latest at time of writing)? Personally I will probably stop using q-io as of now since nothing seems to be happening to address serious issues like this for several months. |
We fixed couple of issue in collections v5.1.3 https://github.com/montagejs/collections/blob/master/CHANGES.md#v513 |
ACK |
Always funny to see a group complain and another making PR to fix the problem. |
Example of person that made PR to remove collections: |
Merged #168 that remove collections in favor of es6-set, I will release today |
I landed here, because of a recursive dependency. The gist is that the mere requiring of the module
collections
randomly breaks code in unrelated modules because it modifies globals. It is documented that this breaks things likecrypto
from node core but there does not seem to be a fix coming: montagejs/collections#162The text was updated successfully, but these errors were encountered: