node-auth0: Fix @types/auth0 inconsistencies with this library

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.

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.

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.

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.

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!

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

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

I’m pleased to report that the Beta of v4 is now available. This has been rewritten in TypeScript and has full type coverage of Auth0’s Management and Authentication APIs.

Closing this thread in favour of https://github.com/auth0/node-auth0/issues/859

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

@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.

@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

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.

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?

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

Example

const auth0 = new ManagementClient(options);

auth0.users.                     // users not found

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.

Thanks for raising this @shellscape - we are actively developing a TypeScript version of this library and we hope to have a Beta out in the next few weeks.

You can follow the progress in the beta branch - for example see the ActionsManager.ts

@jfromaniello This is definitely an interesting approach! But after installing your fork I found that intermediate types are not nearly enough, for example we heavily relies on a generic type AppMetadata<{...}> in our codebase and it is nowhere to be found.

I would suggest a hybrid approach, where methods in AuthenticationClient and ManagementClient are generated from jsdoc, while intermediate types are maintained in separate .d.ts files.

Not sure if this helps or if it should be the route to take but it seems since Typescript 3.7 the compiler can generate the types from JS files with jsdoc params. Fortunately this library has some quite good jsdocs, so I tried it and I’ve to say that I am impressed by the results:

Here are the changes https://github.com/auth0/node-auth0/compare/master...jfromaniello:node-auth0:with_types?expand=1

As you can notice I didn’t add the types to the repo, just added a prepare script to generate them. It also has the declaration map, which makes “go to definition” in vscode works nice.

You can try it out with npm i 'jfromaniello/node-auth0#with_types' --save

Hi @alejandromcsd - thanks for your feedback. This library still relies on the DefinitelyTyped for it’s types, and we currently don’t have a timeline on when that may change. We’ll update this thread when we have any news.

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

We could also put some of these types from @types/auth0 like AppMetadata into a .d.ts file then in the js:

/**
 * @typedef { import("./types").AppMetadata } AppMetadata
 * @typedef { import("./types").UserMetadata } UserMetadata
 * @typedef { import("./types").UserData } UserData
 */

and use these types in the jsdocs:

 /**
   ....
   * @param   {object}      params      The user data object..
   * @param   {string}      params.id   The user id.
   * @param   {AppMetadata} metadata    New user metadata.
   * @param   {Function}    [cb]        Callback function
   * @returns  {Promise|undefined}
   */
  updateUserMetadata(...args) {

Pinging @davidpatrick because this should not be stale.

@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.

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.