Conversation
…g, unknown>`. Remove unneeded disabling of no-trailing-space rule. Replace use of `headers: any` in private `serializeApiCallOptions` method with `Record<string, string>`.
…allResult. Tweak fileUploadV2 return type as a result.
…lines up behaviour with WebClient.
…inor types within its response.
…reaking change enhancements.
8559522 to
e2d2faa
Compare
…ts to reflect docs.
… pass at typing the manifest.
seratch
left a comment
There was a problem hiding this comment.
I can't guarantee everything works as with before but I am confident that this PR is carefully crafted. Great work!
| shouldStop?: PaginatePredicate, | ||
| reduce?: PageReducer<A>, | ||
| ): (Promise<A> | AsyncIterable<WebAPICallResult>) { | ||
| if (!cursorPaginationEnabledMethods.has(method)) { |
There was a problem hiding this comment.
Removing this check is not a big deal at all but did you have to do so due to some changes in this PR? Also, the pagnation method does not provide type-safety for arguments: https://slack.dev/node-slack-sdk/web-api#pagination Do you have any possible ideas to improve it? (not necessarily work on it in this PR)
There was a problem hiding this comment.
Yes, I removed this as I removed the cursorPaginationEnabledMethods variable altogether. I did not find it gave much value (its only use was to issue the warning below). I believe I brought this up in an early discussion internally two months ago or so (search for "from:fil paginate" in our #team-devrel-tools channel internally).
As for ideas on how to improve it, perhaps the API could be changed so that each API method supporting pagination could optionally return an iterator? This way the developer doesn't have to provide the method name string as that would be known by the framework, and the type safety for method arguments provided by this PR would apply as well.
There was a problem hiding this comment.
Thanks for clarifying. Makes sense!
| */ | ||
| public async filesUploadV2(options: FilesUploadV2Arguments): Promise<WebAPICallResult> { | ||
| public async filesUploadV2(options: FilesUploadV2Arguments): Promise< | ||
| WebAPICallResult & { files: FilesCompleteUploadExternalResponse[] } |
| @@ -0,0 +1,224 @@ | |||
| import type { KnownBlock, Block, MessageAttachment, LinkUnfurls, MessageMetadata } from '@slack/types'; | |||
There was a problem hiding this comment.
I am still not 100% confident that all the patterns here are correct ... but well done!
There was a problem hiding this comment.
Yes I think this is a risky area.. all possible combinations of Block elements, etc, may be hard to verify... but I think as long as we are OK to tell developers that find a problem, "please use // @ts-expect-error as a workaround until we release a patch", it should be OK.
| app_home?: ManifestAppHome; | ||
| /** | ||
| * @description A subgroup of settings that describe {@link https://api.slack.com/legacy/enabling-bot-users bot user} configuration. | ||
| * @see {@link https://api.slack.com/legacy/enabling-bot-users Legacy bots}. |
There was a problem hiding this comment.
I don't like linking this "legacy" document here but indeed there is no other document for this
There was a problem hiding this comment.
I took this from the Manifest fields documentation here: https://api.slack.com/reference/manifests#features
The link originally links to api.slack.com/bot-user which redirects to the above link.
|
|
||
| export interface AdminAnalyticsMemberDetails { | ||
| enterprise_id: string; | ||
| team_id: string; |
| @@ -0,0 +1,45 @@ | |||
| import { expectAssignable, expectError } from 'tsd'; | |||
There was a problem hiding this comment.
Thanks for adding these tests!
| @@ -5,7 +5,7 @@ | |||
|
|
|||
Co-authored-by: Kazuhiro Sera <seratch@gmail.com>
…h message-posting APIs, added tests to ensure this remains the case
This work builds off #1670. Web API arguments are worked on to make type safe, though responses were not closely validated as that would require a lot more work. I am also leaving notes on API arguments and responses as I test them out, with breadcrumbs on future improvements / breaking changes.
Once merged, this PR intends to fix #1323.
USEFUL WHEN ASSEMBLING CHANGELOG: For the list of breaking changes introduced, best to look at the
src/methods.tsfile in this commit and search for "TODO".Open Questions
apps.manifest.*APIs in this PR.Deprecations being removed
While here, and since this PR is in prep for a new major release, also took the opportunity to remove methods that were marked as deprecated:
channels.*groups.*im.*mpim.*New Deprecations
We will deprecate the following method groups, given they are mentioned as such in their reference docs.
oauth.access(superseded by the newoauth.v2.*methods)stars.*(docs specifically mention end-users cant interact with them in the client anymore, presumably will be replaced with the Later feature at some point)workflows.*(legacy steps-from-apps related workflow methods)Updates/Testing
Documenting, DRYing up and type-safety-ifying arguments for all the methods against the documentation. Also writing type tests for the arguments as I go.
admin.*:admin.analytics.getFile(need to get unblocked on specific enterprise org setup, should be able to get access to that Monday Nov 27):api.testapps.manifest.*(see open questions above)auth.*bookmarks.*calls.*chat.*conversations.*dialog.opendnd.*emoji.listfiles.*migration.exchangeoauth.*openid.*pins.*reactions.*reminders.*rtm.*search.*stars.*team.*tooling.*usergroups.*users.*views.*workflows.*