Skip to content

Conversation

@vegeris
Copy link
Contributor

@vegeris vegeris commented Apr 9, 2025

Summary

Follow-up to PR 2412

This PR adds the following support for work objects:

  • Updates the inputs for chat.unfurl or chat.postMessage to accept entity metadata
  • Adds the entity.presentDetails API method

Requirements (place an x in each [ ])

@vegeris vegeris changed the title Feat work objects Do not merge: Add support for entity metadata Apr 9, 2025
@vegeris vegeris force-pushed the feat-work-objects branch from f24a1df to 7849554 Compare April 10, 2025 01:34
@codecov
Copy link

codecov bot commented Apr 10, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.02%. Comparing base (16bd88e) to head (3ae9720).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2231   +/-   ##
=======================================
  Coverage   93.01%   93.02%           
=======================================
  Files          40       40           
  Lines       11111    11124   +13     
  Branches      713      713           
=======================================
+ Hits        10335    10348   +13     
  Misses        764      764           
  Partials       12       12           
Flag Coverage Δ
cli-hooks 95.23% <ø> (ø)
cli-test 94.79% <ø> (ø)
oauth 77.39% <ø> (ø)
socket-mode 61.87% <ø> (ø)
web-api 98.08% <100.00%> (+<0.01%) ⬆️
webhook 96.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@vegeris vegeris force-pushed the feat-work-objects branch 4 times, most recently from 9073126 to a1ef919 Compare April 10, 2025 02:21
@vegeris vegeris force-pushed the feat-work-objects branch from a1ef919 to dde54aa Compare April 10, 2025 02:30
@vegeris vegeris force-pushed the feat-work-objects branch from fabc16e to 9e8988b Compare August 22, 2025 18:55
@vegeris vegeris force-pushed the feat-work-objects branch 3 times, most recently from 0517996 to 54b1211 Compare September 10, 2025 14:48
@vegeris vegeris force-pushed the feat-work-objects branch from d759247 to 24ecda6 Compare October 9, 2025 03:02
Copy link
Contributor

@WilliamBergamin WilliamBergamin left a comment

Choose a reason for hiding this comment

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

Great work putting all this together 🙏 types are hard!!

I've left a few comment and questions let me know what you think

Parse &
LinkNames &
Metadata &
ChatPostMessageMetadata &
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ Just want to validate that I'm understanding correctly, this updates ChatPostMessageArguments from

interface ChatPostMessageArguments {
  ...
  metadata?:  {
    event_type: string;
    event_payload: {
      [key: string]: string | number | boolean | MessageMetadataEventPayloadObject | MessageMetadataEventPayloadObject[];
    };
}

To

interface ChatPostMessageArguments {
  ...
  metadata?:  {
    event_type?: string;
    event_payload?: {
      [key: string]: string | number | boolean | MessageMetadataEventPayloadObject | MessageMetadataEventPayloadObject[];
    };
    entities?: EntityMetadata[];
}

Since this type is used to define and input for a function, making event_type and event_payload optional should not be a breaking change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup; what I'm trying to show is that one can provide event and / or entity metadata in chat.postMessage

interface ChatPostMessageArguments {
  ...
  metadata?:  {

   // if providing event metadata, both of these params are still required (but they're optional in the type bc one can provide entity metadata instead)
    event_type: string;
    event_payload: {
      [key: string]: string | number | boolean | MessageMetadataEventPayloadObject | MessageMetadataEventPayloadObject[];
    };


AND / OR

   // if providing entity metadata, this param is required (but it's optional in the type bc one can provide event metadata instead)
    entities: EntityMetadata[];
}

Since this type is used to define and input for a function, making event_type and event_payload optional should not be a breaking change?

Passing an object into the metadata param with just event_type and event_payload is still valid and should still be accepted by the SDK; if users are typing the object as Metadata though they would need to change that to ChatPostMessageMetadata. Similar thing came up for the Java update; changing the type of an existing field does seem like a breaking change 😅 Will work object support require a major version bump because of this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Will work object support require a major version bump because of this?

The the Java SDK I need to take a look there might be a way around this

Comment on lines 286 to 292
type BlockKitUnfurls = {
/**
* @description Object with keys set to URLs featured in the message, pointing to their unfurl
* blocks or message attachments.
*/
unfurls: LinkUnfurls;
};
Copy link
Contributor

Choose a reason for hiding this comment

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

++ on praise for this 🙏

*/
metadata: Partial<MessageMetadata> & {
entities: EntityMetadata[];
};
Copy link
Contributor

Choose a reason for hiding this comment

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

QQ: In ChatPostMessageMetadata, entities is optional, just want to confirm that here is should be required

@vegeris
Copy link
Contributor Author

vegeris commented Oct 22, 2025

I'm not sure what's going on with the failing tests in the cli-test package;

 Exception during run: src/cli/shell.spec.ts(21,55): error TS2345: Argument of type 'SpawnSyncReturns<Buffer<ArrayBufferLike>>' is not assignable to parameter of type 'SpawnSyncReturns<string | NonSharedBuffer>'.
...

It seems like the object being passed in matches the interface

    runOutput = { pid: 1337, output: [], stdout: Buffer.from("[]"), stderr: Buffer.from("[]"), status: 0, signal: null };
    runSpy = sandbox.stub(child, 'spawnSync').returns(runOutput);

Edit: resolved!

@vegeris vegeris changed the title feat: add support for work objects feat: add support to @slack/web-api for work objects Oct 23, 2025
Copy link
Contributor

@WilliamBergamin WilliamBergamin left a comment

Choose a reason for hiding this comment

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

🚢

"dependencies": {
"@slack/logger": "^4.0.0",
"@slack/types": "^2.17.0",
"@slack/types": "2.18.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice 💯

Copy link
Contributor

@WilliamBergamin WilliamBergamin left a comment

Choose a reason for hiding this comment

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

Quick change actually

Co-authored-by: William Bergamin <wbergamin@salesforce.com>
Copy link
Contributor

@WilliamBergamin WilliamBergamin left a comment

Choose a reason for hiding this comment

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

🚀

@vegeris vegeris merged commit 9ed8713 into main Oct 24, 2025
57 checks passed
@vegeris vegeris deleted the feat-work-objects branch October 24, 2025 14:36
@vegeris vegeris added this to the web-api@7.12.0 milestone Nov 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement M-T: A feature request for new functionality pkg:types applies to `@slack/types` pkg:web-api applies to `@slack/web-api` semver:minor

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants