👍 I guess we missed this in our rewrite. Thanks for catching the bug!

@jeanettehead Can you add a test for this so future contributors don't remove this functionality out from under you by accident?

@clayreimann The CI is failing on master again for a change unrelated to this one.

@mtscout6 I looked at testing it, but I didn't see any existing tests for the existing pagination behavior, or fixtures with paginated results. Is there something in there that I missed?

I don't think there is existing support for testing the explicit pagination that you are introducing. The other testing there is testing that all data is fetched, regardless of pagination.

@mtscout6 That builds are still failing is related to the flakeyness of github's APIs. To fully solve that problem we need to make sure that all of the tests are fully isolated and then configure the tests to retry a couple times when they fail.

@mtscout6 any update on this?

I looked into testing it again, and I'm not really interested in implementing the setup required to test this one line change. The existing tests in user -> list repos are just testing that an array is returned - not that any particular data length comes back, and there no tests at all for the requestable object that was modified. Setting up a new test and fixtures for this seems like a lot relative to the change footprint.

Without tests there will be no guarantee that we don't accidentally remove this in the future. If your ok with that then ok.

I'm OK with that.

@clayreimann I don't have permission to push this to npm. Can you do that as a minor version bump?

@mtscout6 I pushed a new minor version. Therelease script doesn't push to npm directly, we do that from our travis build so you should be able to release versions whenever you like.

e.g.npm run release -- minor

Looks like this broke the build 😢

@jeanettehead

@clayreimann Note that I mentioned earlier that the CI was already broken on master before she submitted this PR:#409 (comment)

Ahh, I guess I misunderstood.