Use String Literals for Fixed-Value Fields in API Responses in 6.0.0

[kang8]

Description:

Today, while upgrading the Intercom SDK to version 6.0.0, I found it to be very useful. However, I noticed that the type definitions for some response fields could be improved. MPany API responses include fields that are currently typed as plain string but are actually constrained to a limited set of valid values. For example, the source.type field in retrieve a conversation typically returns values like 'conversation', 'email', 'facebook', 'instagram', 'phone_call', 'phone_switch', 'push', 'sms', 'twitter', and 'whatsapp'.

Proposed Enhancement:

I propose updating the type definitions across the library to leverage TypeScript string literals for fields with a fixed set of possible values. This change would ensure that fields representing specific categories or types use explicit string literal types rather than the generic string.

Benefits:

• Improved Type Safety: This guarantees at compile time that only valid values can be assigned to fields with restricted sets, reducing potential runtime errors.
• Enhanced Developer Experience: Developers benefit from better autocompletion, code documentation, and guidance in their IDEs, making it easier to work with the library.
• Better Code Clarity: Clearly defined literal types make the code more self-descriptive and maintainable by documenting valid values directly in the types.

Implementation Considerations:

Given that the intercom-node types might be auto-generated—as suggested by comments such as:

/**
 * This file was auto-generated by Fern from our API Definition.
 */

It may require adjustments in the type generation process to incorporate string literals. I would appreciate guidance on how the generation pipeline could be adapted to include these improvements.

Feedback and Collaboration:

I am keen to contribute by helping with this enhancement. I would welcome any insights into how the types are being generated and any specific areas to focus on to effectively integrate these suggested changes.

[fern-support]

@kang8 thanks for writing this detailed issue and I agree with you typing as a literal instead of a string would be a better developer experience. Would you be open to making a pull request to the 2.11 OpenAPI spec here ?

[fern-support]

A handful of PRs have addressed this by introducing enums where relevant, which after SDK generation instantiates as a string literal; intercom/Intercom-OpenAPI#185, intercom/Intercom-OpenAPI#195, and recently intercom/Intercom-OpenAPI#222 add them in wherever we noticed it was missing. For now we'll close the issue; feel free to ask to reopen if the issue recurs!