Refactor Error Classes

[jherdman]

This breaking change accomplishes a few things:

• Deprecates the AjaxError#errors property. Going forward we'll do much
  less with errors, and instead simply provide the payload from the
  server's error response. The payload will be accessible via the
  #payload property.
• Refactors Ajax Error, and friends, into ES6 classes. This is
  potentially a breaking change as we no longer inherit from
  Ember.Error.

Closes #175

[coveralls]

Coverage remained the same at 100.0% when pulling bbb5865 on jherdman:issue-175 into 3ebfef0 on ember-cli:master.

[alexlafroscia]

Thanks @jherdman! This all looks 👌 to me.

I think we should make a v3.0.0 branch to merge these things to for now, so that we can land non-breaking changes for the time being (like the deprecation warnings when using the existing error normalization method) without having to ship these breaking ones, too. Does that sound good? If so, update this PR to merge into v3.0.0 (which I'll make right now).

[jherdman]

Shouldn't this merge before 3.0? I believe the release target should be 2.6. If not, I may need to update the target version this deprecation will be removed.

[alexlafroscia]

If it's a breaking change then it can't land before v3.0.0 right? I mean, the chances that people are checking that AjaxError is an instance of EmberError are slim, probably, but it's still a breaking change and we really shouldn't add it without a major version bump in order to respect semver.

[jherdman]

My apologies, you're correct. Before we merge this we ought to decide when we'll remove the errors property to update the until: tag.

[jherdman]

@taras our snazzy fixup has been pushed!

[jherdman]

Fails look like rubbish. @taras are you able to kick the builds?

[taras]

@jherdman I don't think I can. Can you please push an empty commit with: git commit -m "Kicking CI" ---allow-empty

[coveralls]

Coverage remained the same at 100.0% when pulling c0beb8a on jherdman:issue-175 into 3ebfef0 on ember-cli:v3.0.0.

[jherdman]

Gah! AppVeyor is being a jerk. I'll investigate the fails today.

[alexlafroscia]

I've been thinking lately that we should just drop AppVeyor. It's constantly slow and unstable, and we don't do anything that should be different with Broccoli that should be different between Windows and Linux. Every time I've seen a failure on there, it's just AppVeyor being a butt and not an actual Windows issue.

[jherdman]

@alexlafroscia yeah, totes. Especially if we're just building against Chrome on Windows.

[coveralls]

Coverage remained the same at 100.0% when pulling a133e63 on jherdman:issue-175 into 3ebfef0 on ember-cli:v3.0.0.

[jherdman]

OK, so Ember 1.13 is failing consistently on AppVeyor. One fail, fine, two? Not so cool. Three: we've got a problem.

I've managed to pooch something on my machine tonight, but I'll do my best to look into this soon.

[taras]

@jherdman yeah, that's weird. Gotta checkout in 1.13 and figure out why it's dying.

You can do: ember try ember-1.13 --skip-cleanup and it'll switch to 1.13

[jherdman]

@alexlafroscia do you mind updating the 3.0 branch? There are some spurious commits in this.

@taras so, the most recent commit fixes the fails for 1.13. It seems like 1.13 always raises on deprecation. I thought about detecting 1.13 and telling it not to throw, but that seemed more complicated than actually fixing some tests now. Thoughts?

[coveralls]

Coverage remained the same at 100.0% when pulling 3c916d8 on jherdman:issue-175 into 3ebfef0 on ember-cli:v3.0.0.

[jherdman]

CI is ruining me...

[coveralls]

Coverage remained the same at 100.0% when pulling 48509fa on jherdman:issue-175 into 3ebfef0 on ember-cli:v3.0.0.

[jherdman]

Ping @alexlafroscia @taras . If y'all are happy, I'll squash this down and push it back up.

[taras]

No worries, merged :)

[jherdman]

💃

[taras]

Thank you for helping us push this through :)