Parse.Promise.when callback arguments should match the format of promises passed in

[braker1nine]

For example

var p1 = Parse.Promise.as('Thing1');
var p2 = Parse.Promise.as('Thing2');
var promiseArray = [p1,p2];
Parse.Promise.when(promiseArray).then(function(results) {
  console.log(results); // should be an array containing 'Thing1' and 'Thing2'
});

[andrewimm]

Are you suggesting that when passing promises as arguments, the result should return them as arguments, and when calling as an array it should return them as an array?

If so, I agree. That should be a pretty easy fix.

[braker1nine]

@andrewimm yep that's exactly what I'm suggesting. Would make it much simpler to deal with a dynamic number of promises.

Unless you'd prefer to, I can put together a PR. Just didn't want to do it if this was an intentional design decision.

[andrewimm]

If you want to go ahead with a PR, please do. We're a bit busy with the new site launch today :)

[TylerBrock]

Hey, no big deal here, just a BACKWARD BREAKING change that is not documented anywhere... no change log or anything.

[andrewimm]

@TylerBrock you're absolutely right. I should have given this more consideration. How do you suggest we handle this?

[andrewimm]

I'm considering paths forward. In examining the developer benefits of this change, I neglected to realize that it would break past apps.

As great as it would be to simplify this, my current plan is to revert this commit and remove 1.6.10 from npm.

[andrewimm]

Reverted and published as 1.6.11.

That said, Tyler, if these sorts of changes are affecting you in production, you should really lock down your package.json to reference explicit version numbers.

[braker1nine]

Understand not wanting to make breaking changes. Sorry for the inconvenience @TylerBrock

I still think it's a clear improvement that should be used. Any policy for that? Documentation-wise I screwed up. Changes from #116 should have been included in the PR

[TylerBrock]

This actually solves a pain point for us and we love this change. No issues there.

This release did not affect us deployment/production-wise as we are explicit about package versions. I was just concerned that the change was not communicated at all. Unless you watch this repo like a hawk you'd have no idea why code that works against 1.6.9 is totally broken in 1.6.10.

Essentially, I was sitting here wanting to upgrade but not sure what has happened in between the last release and this one.

I know the project is not semantically versioned but most people do not expect things to break in a patch level release (and I have to think at least some people out there coming to the Parse platform simply npm install parse without a shrinkwrap) and would fall victim to an update like this hosing their project in production on a subsequent deploy.

[lacker]

I agree with Tyler, let's consider this an error and try to avoid this level of breakery in the future.

[andrewimm]

While the project is not semantically vendored, this is definitely a change that should go in a minor version bump, not a patch. That seems the safest route.

[TylerBrock]

Great, thanks all!

[braker1nine]

@andrewimm @lacker can we reopen this issue since it seems to be generally agreed that it is an issue in need of improvement, even if the deployment wasn't handled optimally?