Fix @types/auth0 inconsistencies with this library

[vicary]

Describe the problem

Relocated from community forum (53190).

From earlier technical support enquiries I know that the SDK method ManagementClient#passwordGrant() in fact takes an undocumented second argument { forwardedFor } to sent the Auth0-Forwarded-For header. Since server-side authentication requires the option to prevent blocking, I would like to know if there are plans to add the definition in the official SDK documentation?

The TypeScript/DefinitelyTyped community is confused about this and I think we need official comments to move on.

What was the expected behavior?

https://auth0.github.io/node-auth0 and @types/auth0 should reflects the implemented features and actual behaviour of this repo.

Reproduction

npm install @types/auth0

Environment

• Version of this library used: 2.20.12
• Which framework are you using, if applicable: Serverless
• Other modules/plugins/libraries that might be involved: DefinitelyTyped, TypeScript
• Any other relevant information you think would be useful: N/A

[davidpatrick]

Thanks @vicary for raising the issue. Let me talk with the team about the possibility of bringing the types into this library.

[franklin-ross]

I just came across this myself by tracing through the code and noticing the hidden extra param. At the very least, could someone move on updating the docs where they are? Moving them here would be great, but sounds less quick.

[vicary]

I just came across this myself by tracing through the code and noticing the hidden extra param. At the very least, could someone move on updating the docs where they are? Moving them here would be great, but sounds less quick.

We the community may trace out types (i.e. @types/auth0) according to official documentations (i.e. https://auth0.github.io/node-auth0). But it is really not easy for others to reverse engineer the whole thing from source, let alone keeping up with changes here in this repo.

[davidpatrick]

Thanks @vicary and @franklin-ross for raising visibility. We agree that maintaining the types in this library is the correct path. Let me discuss with the team on the best path forward for migration.

[danawoodman]

Another mismatch is the management.getUser() API which the type says returns an object of the user attributes but instead returns an array of a single user object. Either the library should return 1 result (as you would expect) or the types should be adjusted 👍

[vicary]

@danawoodman I think your issue should be tracked separately, yours could be a documentation mismatch, or a genuine implementation mistake.

This issue is about TypeScript types matching the current codebase AND documentations, not the other way around.

[franklin-ross]

I noticed a few others: getJobErrors() and importUsersJob() exist and can be called, but aren't documented on the types at all. It's especially confusing because importUsers() does exist in the types, but is deprecated and suggests using importUsersJob() which doesn't show up in the editor.

[stevehobbsdev]

Thanks for continuing to raise these discrepancies @franklin-ross. We've had conversations within the team and we do want to take ownerships of these types. Not sure what that looks like yet and it's a matter of prioritization; as soon as we have an update to share, we'll post it here.

[thgh]

Not sure if this requires a new issue, but I notice a lot of optional fields and I don't understand how this could happen.

e.g. AuthenticationClient

or Connection, it would be interesting to include a comment that explains why it might be missing.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇‍♂️

[vicary]

Pinging @davidpatrick because this should not be stale.

[kkomelin]

We miss Organizations types. Please add to ether @types or to this project. Thanks in advance.

[sukruavcuoglu]

any estimation for adding Organization types?

[namoscato]

In the meantime, you can augment the DefinitelyTyped definitions with a module in your own codebase, i.e.

import * as auth0 from "auth0";

declare module "auth0" {
  /**
   * @see https://auth0.com/docs/api/management/v2/#!/Organizations/get_organizations
   * @see https://auth0.github.io/node-auth0/module-management.OrganizationsManager.html
   */
  export interface OrganizationsManager {
    getEnabledConnections({
      id: string,
    }): Promise<
      Array<{
        connection_id: string;
        assign_membership_on_login: boolean;
        connection: {
          name: string;
          strategy: string;
        };
      }>
    >;
  }

  export interface ManagementClient {
    organizations: OrganizationsManager;
  }
}

Realistically, I don't have time to help out with all of these definitions but am happy to help out with what I can. We really just need some clarity from Auth0 on how and when the TypeScript support for this library evolves. From all of us on this thread, thank you in advance for your efforts around prioritization!

[omnibrain]

Sorry for asking again, but any news on the organization types? This really slows us down 😞 If at least we had some idea when we can expect the types to be implemented so we could decide if we should do it ourselves or wait for the official types.

Or does anyone in this thread maybe have an implementation that we could use as a basis?

[frederikprijck]

Support for Organizations has been added as part of "@types/auth0": "^2.34.0",, if you update to the latest version you should be able to use client.organizations.getAll() etc.

[kkomelin]

That's very good news @frederikprijck! Thank you very much to you and everyone who was involved in delivering the Organizations API support.

[mistycal98]

Support fot UserManager in @types/auth0 for nodejs currently only organizations is available

Example

const auth0 = new ManagementClient(options);

auth0.users.                     // users not found

[Roustalski]

Any update here or ETA? Is this still in the backlog or prioritized to have this worked soon?

[adamjmcgrath]

Hi @Roustalski - we do have plans to manage these types in the long term, but don't have an ETA for you I'm afraid. For the time being you should continue to rely on the community provided types on DT

[mistycal98]

Okay

On Tue, 11 Jan, 2022, 6:37 pm Adam Mcgrath, @.***> wrote:

Hi @Roustalski https://github.com/Roustalski - we do have plans to manage these types in the long term, but don't have an ETA for you I'm afraid. For the time being you should continue to rely on the community provided types on DT

— Reply to this email directly, view it on GitHub https://github.com/auth0/node-auth0/issues/572#issuecomment-1009947490, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARTS45J7D2JCS46I526QIVTUVQTSJANCNFSM4WAORB6A . You are receiving this because you commented.Message ID: @.***>

Tushar

[EdNutting]

Unfortunately the community-provided types in DT, while an admirable effort, are severely mismatched to the functionality actually implemented by this package. To the point of requiring the use of "any" to bypass areas where the types are outright wrong.

Please prioritise providing proper type definitions as part of the release of this package. I sincerely hope a multi-million dollar organization like Auth0 (now Okta) owns this repo (i.e. I don't know but hope this isn't also a community-run development) and recognises that developers need good tools to be able to use their product. The thread here and the fact that this is a TypeScript package still relying on DT to provide types (and community-maintained ones at that), is both rather concerning and confusing.

In the meantime, I guess we'll live with casting the ManagementClient to "any" and calling things as best we can figure out.

[vicary]

As OP I don't want to drive this thread too much towards negativity, but I admit users do have their limits in patience.

@EdNutting Adding to your point about resource allocation. When you look at the JavaScript sources, it is a simple request curry. API iterations should induce minimal maintenances towards the actual source, the SDK team (if it has one) should be mainly focused on keeping the DT up to date. Should be achievable with a headcount and a half.

auth0's current model really does not favor community driven developments unless there is self-host option like how GitLab do it, otherwise they have to take it themselves.

[kkomelin]

@vicary I agree that it should be an SDK team responsibility to support the typings. And it may not be that hard because TypeScript compiler can actually generate typings by JS files.

npx -p typescript tsc src/**/*.js --declaration --allowJs --emitDeclarationOnly --outDir types

Creating .d.ts Files from .js files

[prattcmp]

+1. Is this prioritized in the backlog?

[ALVNCHNG]

+1 for this. Having some typing issues especially on AuthenticationClient

[jonasschultheiss]

Please add the types in this repo. i have to check if a user is in an organisation and it's a pain to do it without this function: https://auth0.github.io/node-auth0/UsersManager.html#getUserOrganizations

[Stono]

Probably related:

• https://github.com/auth0/node-auth0/issues/733
• https://github.com/auth0/node-auth0/issues/732

[jdjkelly]

@kkomelin is right:

@vicary I agree that it should be an SDK team responsibility to support the typings. And it may not be that hard because TypeScript compiler can actually generate typings by JS files.

npx -p typescript tsc src/**/*.js --declaration --allowJs --emitDeclarationOnly --outDir types

Creating .d.ts Files from .js files

• The library should prioritize emitting TS typings and ensuring types is in the release using the one liner above.
• Missing types on UserManager for example missing getUserOrganizations https://auth0.github.io/node-auth0/UsersManager.html#getUserOrganizations force implementer use of any
• @types/auth0/DefinitelyTyped mentioned in the root of the is project is a separate concern. node-auth0 should emit its own types first. See more in this Stackoverflow answer.

[Alex-Yakubovsky]

@jonasschultheiss I needed getUserOrganizations as well; I put a PR to add the type definition