Many methods won't work correctly without `stringify_ids` set to true
lostfictions opened this issue · 1 comments
Describe the bug
Hey there, thanks for this library! Unfortunately I'm experiencing quite a few footguns while trying to use it. I understand that it's trying to be a fairly close mapping to the Twitter API, but in my opinion some parameters should be set by default, or else package consumes are going to experience strange, confusing errors.
Case in point: several methods get a list of user IDs -- for example, client.accountsAndUsers.friendsIds()
and client.accountsAndUsers.friendshipsNoRetweetsIds()
. If these are called without passing stringify_ids: true
as a parameter, the results they return may be invalid. For example, if I do this:
const { ids: userIds } = await client.accountsAndUsers.friendsIds();
const tl = await client.tweets.statusesUserTimeline({
user_id: userIds[0],
count: 3,
});
I get a confusing 404 error. This is because the list of IDs is invalid (and the Twitter API can't detect it and provides a very poor error code in response). To make this code work, I have to do this:
const { ids: userIds } = (await client.accountsAndUsers.friendsIds({
stringify_ids: true,
})) as unknown as { ids: string[] };
const tl = await client.tweets.statusesUserTimeline({
user_id: userIds[0],
count: 3,
});
Unfortunately, this package isn't smart enough to parametrize the return type of this endpoint based on whether stringify_ids
is set, so we need to perform a double-cast to manually specify the type that's actually returned.
Expected behavior
This package should probably automatically set stringify_ids
to true
whenever it's available as a parameter. The Twitter API documentation prominently mentions on several pages that this parameter is strongly recommended to be set when using languages like JavaScript. While this would technically be a breaking change, I think it's worth it to help smooth over a serious footgun (and typings that are wrong to boot). Maybe it could be released as a semver-major bump?
I understand that this would deviate from providing a "clean" mapping to the Twitter API, but if this deviation were documented clearly in the readme (and if the typings accurately reflected the stringified return types for the affected calls) I think the benefit would be significant.
Package Manager:
Yarn
Relates to #57.