Mismatched types

[zomchak-code]

Describe the Bug
Types are not matching actual values returned

Example Code

const ticket = await client.tickets.show(392005);
console.log({ id: ticket.id, response: ticket.response });

Expected Behavior
Either .id reported as type error or following output:

{
  id: 392005,
  response: undefined
}

Actual Behavior
Either .resource reported as type error and following output:

{
  id: undefined,
  response: {
    json: [Function: json],
    status: 200,
    headers: {
      get: [Function: get]
    },
    statusText: "OK"
  }
}

Environment Information

• node-zendesk version: 5.0.7
• Node.js version: 20.2.0
• Operating System: MacOS
• Any other relevant software versions?

[mackstann]

I'm seeing something similar with the TS types. I'm making a users.createOrUpdate call. The types say it returns a Promise<User>. But when the promise resolves, I don't have a User, I have a wrapper object with response and result properties. result is of type User.

Paste of the method declaration in 5.0.9 from my node_modules:

    /**
     * Creates or updates a user.
     * @param {object} user - The user details.
     * @returns {Promise<User>} The created or updated user's details.
     * @async
     * @see {@link https://developer.zendesk.com/api-reference/ticketing/users/users/#create-or-update-user}
     * @example
     * const user = await client.users.createOrUpdate({name: 'John Doe', email: 'john@example.com'});
     */
    createOrUpdate(user: object): Promise<User>;

And the original JS declaration in the repo:

node-zendesk/src/clients/core/users.js

Lines 190 to 201 in ac07d2c

	/**
	* Creates or updates a user.
	* @param {object} user - The user details.
	* @returns {Promise<User>} The created or updated user's details.
	* @async
	* @see {@link https://developer.zendesk.com/api-reference/ticketing/users/users/#create-or-update-user}
	* @example
	* const user = await client.users.createOrUpdate({name: 'John Doe', email: 'john@example.com'});
	*/
	async createOrUpdate(user) {
	return this.post(['users', 'create_or_update'], user);
	}

Paste of the actual resolved value:

{
  response: {
    json: [Function: json],
    status: 201,
    headers: { get: [Function: get] },
    statusText: 'Created'
  },
  result: {
    id: ...,
    ... other User properties ...
  }
}

[binarypie]

I have the same issue with users.show where it expects to return a Promise<User> but the actual response value is Promise<{result: User}>

[jckw]

I just contributed to the bounty on this issue.

Each contribution to this bounty has an expiry time and will be auto-refunded to the contributor if the issue is not solved before then.

To make this a public bounty or have a reward split, the maintainer can reply to this comment.

[owenshaupt]

ditto — exactly what @mackstann is seeing returned is also returning for me when using users.update

[andoshin11]

any update on this?

[pano9000]

having the same issue with users.update.
If I recall correctly also similar thing with organizations.showMany was happening, where the types expect an array of numbers, while in reality it also seems to correctly accept a single number, not in an array.

[fahadbshahid]

Having similar issue with tickets.create, the documentation/comments suggest some thing else for payload whereas the code is working with original ZendeskAPI payload with error for types.

In the documentation it suggests;
const newTicket = await client.tickets.create({ subject: 'New ticket', description: 'Ticket description' });

[blakmatrix]

Hi @fahadbshahid

Thank you for reporting this issue and for your patience! After reviewing the current code and type definitions, it looks like we've resolved many mismatched types in recent updates. Based on what I can see in the latest version, the types should now align correctly with the documentation and payload structure.

It's possible this issue is due to using an outdated version of the library. Could you please try updating to the latest version and see if the issue persists?

If you still encounter the problem, feel free to open a new issue or, if you're comfortable, submit a PR with a fix. We appreciate your contributions and want to ensure everything works smoothly for you.

I'll go ahead and close this ticket for now to keep things tidy, but we're here if you need further help!

Best,
Farrin