Why is the property added collection and not collections? about collections HOT 3 OPEN

I'll be honest, I'm pretty stumped on this one. Fiddling with the tests:

it('should add the collection property to a file', function(done){
    var metalsmith = Metalsmith('test/fixtures/pattern');
    metalsmith
      .use(collections({
        articles: '*.md'
      }))
      .build(function(err, files){
        if (err) return done(err);
        console.log(typeof files['three.md']['collection'])
        assert.equal(files['three.md'].collection, ['articles']);
        done();
      });
  });

typeof files['three.md']['collection'] === object

So it is definitely an array.

However the test only passes when asserting that collection is a string...

EDIT:

The tests are passing because assert.equal, which tests "shallow, coercive equality", is being used. It would be very nice to have some clarity here: if the authors of the plugin intended for the collection property on each file to be an array of collection names, an array of collections with files, one string collection name, or, an array of one element - a string containing the collection name...

from collections.

It's from when it was originally written. I think the thought process was that the plugin handles collections and each one is a collection.

from collections.

@benpolinsky @woodyrew There is actually a very, very compelling reason to do this that I accidentally stumbled upon.
When using only a plugin like layouts, the global metadata keys are overwritten by the file-specific metadata keys. To allow access to both (one being all the collections, and the other a string or an array of strings) the local "collection" key cannot match the global metadata "collections" key.

Furthermore looking into this made me realize collection is not guaranteed to be an array, in fact if a single collection is added, it will be a string

from collections.