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

collections breaks Array.from with Iterables #169

Open
akloeber opened this issue Dec 26, 2016 · 12 comments · May be fixed by #173
Open

collections breaks Array.from with Iterables #169

akloeber opened this issue Dec 26, 2016 · 12 comments · May be fixed by #173
Assignees
Labels
Milestone

Comments

@akloeber
Copy link

akloeber commented Dec 26, 2016

collections breaks Array.from with Iterables. This can be reproduced with the following code:

var obj = {};
obj[Symbol.iterator] = function() {
  var values = ['foo', 'bar'];

  return {
    next: function() {
      var done = values.length === 0;
      var value = done ? undefined : values.shift();

      return {
        value: value,
        done: done
      };
    }
  };
};

console.log('before collections load:', Array.from(obj));
require('collections/sorted-map');
console.log('after collections load:', Array.from(obj));

Output:

$ node test.js
before collections load: [ 'foo', 'bar' ]
after collections load: []

Environment:
collections v5.0.6
node v4.4.7
Mac OS X 10.12.2

@akloeber akloeber changed the title collectionjs breaks Array.from with Iterables collections breaks Array.from with Iterables Dec 26, 2016
@a-x-
Copy link

a-x- commented Feb 8, 2017

It implicitly breaks our code too (i had got 4 debug hours) :(

@a-x- a-x- linked a pull request Feb 8, 2017 that will close this issue
@FrozenPrincess
Copy link

Yeah, I lost the better part of a day to this too. It broke some code completely unrelated to anything near the collections stuff, and ended up being a real bitch to track down.

Blindly overwriting Array.from seems like a bad idea, but to do it with a non-conformant implementation really blows my mind.

@marchant
Copy link
Member

This Array.from may have been written before the current one even existed or was final. Iterators changed in the past 5 years. So if you're happy with the rest of this library, give the author(s) some credits there. Thanks @a-x- for the PR, it's a step in the right direction to use the native implementation when available, but the shim has to be re-aligned and do what native Array.from does, contributions welcomed!

@kriskowal
Copy link
Member

This issue is addressed with Collections version 2. However, this is not backward-compatible with the MontageJS install base, so it is not default. npm install collections@2 to use a modern version that does no monkey patching (unless you make an array instance mutations observable).

@Torniojaws
Copy link

Torniojaws commented Oct 18, 2018

The same for Array.prototype.find().

Before:

[5, 12, 8, 130, 44].find((element) => {
  return element > 10;
});
// returns 12

After:

[5, 12, 8, 130, 44].find((element) => {
  return element > 10;
});
// returns -1 
// and also breaks Joi.validate() because of this 

It is a really dangerous game to modify built-in prototypes.

@sergey-shevchuk
Copy link

Array.from takes only first parameter into account
Expected syntax: Array.from(arrayLike[, mapFn[, thisArg]])

console.log('before collections load:', Array.from([1, 2, 3], x => x + x););
require('collections/sorted-set');
console.log('after collections load:', Array.from([1, 2, 3], x => x + x););

Output:

$ node test.js
before collections load: [ 2, 4, 6 ]
after collections load: [ 1, 2, 3 ]

@kriskowal
Copy link
Member

In my opinion, a major version needs to be released that removes these shims. The simplest solution would be to republish version 2 as a new major that jumps ahead of the latest major versions that are designed to retain backward compatibility with MontageJS.

However, I am no longer vested in this effort. The best people to make this call are @marchant and @hthetiot, who have most recently contributed substantially.

@Stuk and I did have an alternative idea to publish these collections as individual packages under @collections in npm and did a bunch of the footwork, but did not follow through. https://github.com/kriskowal/collections My involvement in JavaScript volunteerism has waned in recent years, since I’m putting more of my time at work in Golang and more of my time at home in text adventure games.

I’m all for enabling any volunteers to bring Collections into the modern era. I imagine this will involve deprecating collections in favor of @collections/* modules and leaving a big note that collections should not be used anymore. This would also involve a pretty substantial update to collectionsjs.com.

@codebling
Copy link

codebling commented Apr 15, 2019

See also issues #36 #70 #94 #95 #116 #139 #145 #162 #165 #169 #178 #182 #185 #197 #215 #220 #221 and PRs #94 #95 #116 #173 #189 #212. As mentioned, branch v2 fixes these issues by avoiding global object modification.

@gary-harpaz
Copy link

Another victim here. v2 branch solved the issue but I really think a warning should be added to:
https://www.npmjs.com/package/collections
Like in giant red

@aditya1711
Copy link

aditya1711 commented Jun 10, 2020

Array.length gets broken for some libraries in React Native, maybe React also, like Victory Native, React native SVG, etc.

I can reproduce the error if required.

Need a fix or workaround for this. Please help.

@codebling
Copy link

@aditya1711 have you read the conversation above? Proposed solution is to use v2 branch. Have you tried this?

@aditya1711
Copy link

@aditya1711 have you read the conversation above? Proposed solution is to use v2 branch. Have you tried this?

Okay, I didn't know it didn't get merged with the master. It's working now. Thanks a lot for your help and a quick reply.

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

Successfully merging a pull request may close this issue.