Skip to content

Conversation

cgpuglie
Copy link
Contributor

Resolve #3

Added promise support and associated tests and documentation.

@cgpuglie
Copy link
Contributor Author

Huh, the tests pass, but the command to prettify it for travis is failing for some reason. I'll see if I can get that to work.

- Follows style of other code
- Plus it was making the parser upset for the tests
@coveralls
Copy link

Coverage Status

Coverage increased (+0.5%) to 87.85% when pulling 087f2cc on cgpuglie:feature/support-promises into fae42a6 on zencoder:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.5%) to 87.85% when pulling 4db79cd on cgpuglie:feature/support-promises into fae42a6 on zencoder:master.

@cgpuglie cgpuglie requested review from dmikalova and dhowellbc and removed request for corasaurus-hex and jgreer November 30, 2017 21:53

//request doesn't think 4xx is an error - we want an error for any non-2xx status codes
//we also we want this to be a real error object...
if (!err && (response.statusCode < 200 || response.statusCode > 206)){

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not check for > 299 rather than > 206 to cover all 2xx?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's from the original function, so that one's on me, not @cgpuglie. It's been a while, but if I recall correctly this was something I saw in another SDK that took a similar approach to non-success code handling when using Request. I personally don't see any issue with just making the logic > 299, but to be fair 206 is the last "official" 2xx status code. ¯\_(ツ)_/¯

.reply(200, scopes.accounts.details)
.post('/api/v90/jobs')
.post('/api/v90/jobs').times(2)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why /api/v2/ and then /api/v90?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a test to ensure the 404 error handling returns an error object.

@dmikalova
Copy link

Looks good, just had 2 miscellaneous questions.
:shipit:

Copy link
Contributor

@mmcc mmcc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥🔥🔥

Not that my approval matters of course, just checked out the PR when I was updating the npm maintainers :)


//request doesn't think 4xx is an error - we want an error for any non-2xx status codes
//we also we want this to be a real error object...
if (!err && (response.statusCode < 200 || response.statusCode > 206)){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's from the original function, so that one's on me, not @cgpuglie. It's been a while, but if I recall correctly this was something I saw in another SDK that took a similar approach to non-success code handling when using Request. I personally don't see any issue with just making the logic > 299, but to be fair 206 is the last "official" 2xx status code. ¯\_(ツ)_/¯

.reply(200, scopes.accounts.details)
.post('/api/v90/jobs')
.post('/api/v90/jobs').times(2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a test to ensure the 404 error handling returns an error object.

@@ -1,6 +1,6 @@
{
"name": "zencoder",
"version": "1.1.0",
"version": "2.0.1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, this feels like it could technically be a minor bump if you wanted to. As far as I can tell no current functionality is broken (👍 ), so it shouldn't break anything for folks that are pinned to 1.x.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with major since it will no longer work with node 0.1.0, which was the original version requirement. Wanted to use native promises which require 6.4 or above.

I'm open to doing a minor if you'd prefer it though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That reasoning makes total sense to me 👍

@cgpuglie cgpuglie merged commit 04d64f4 into zencoder:master Jan 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants