feat: allow specifying channel roles for members in campaigns

[Acconut]

CLA

• I have signed the Stream CLA (required).
• Code changes are tested

Description of the changes, What, Why and How?

The CreateCampaign endpoint allows to specify a channel template that applies to newly create channels. This template can also contain a list of user IDs that should be added to these channels as members. A customer requested that they also want to be able to specify specific channel roles for these members, so they are not added with the default channel_member role.

I've been working on the corresponding changes on the backend, so that it accepts lists of user IDs as well as objects in a backward-compatible way to accommodate the existing usage of CreateCampaign:

client.createCampaign({
  channel_template: {
    type: 'messaging',
    // Current format (still possible)
    members: ['moderator-1'],
    // Now also possible
    members: [
      {
        user_id: 'moderator-1',
        channel_role: 'channel_moderator',
        key1: 'custom-key-1',
      },
    ],
  },
  ...
})

This PR updates the types used in the createCampaign and getCampaign methods to allow the new object array form, as well as the user ID array form.

One concern I have is that this is in theory a breaking change for the getCampaign method, as the type for members changes from string[] to string[] | CampaignChannelMember[]. I implemented the backend changes in such a way that GetCampaign preserves the format of members that was supplied in CreateCampaign. A customer that passed a user ID array when creating the campaign, will still get an array back. However, it might still lead to breaking changes because the members property can now also be CampaignChannelMember[]. What's the best way to deal with this? Release this in the next major release? Implement the feature in a different way?

Changelog

[github-actions]

Size Change: 0 B

Total Size: 354 kB

ℹ️ View Unchanged

Filename	Size
dist/cjs/index.browser.js	118 kB
dist/cjs/index.node.js	119 kB
dist/esm/index.mjs	117 kB

_{compressed-size-action}

[MartinCupela]

Hey @Acconut, typescript will complain when accessing the members in response. The integrators will need to add type checking. What you could do is to add another property that will contain the union (But that again will lead to confusion when documenting it.) or just the new type, and leave the original members as a string array and deprecate it (in case of having union in the new field).

[Acconut]

Thank you for the comment, Martin! You're completely right that this presents a breaking change. We discussed this internally as well and decided to go with a separate property instead of changing the type of an existing one. That way no existing users will be impacted. This was merged in #1647 already and I should have closed this PR earlier. Apologies about that!