ESM support

[btakita]

fixes #783

Changes

Please describe both what is changing and why this is important. Include:

• Endpoints added, deleted, deprecated, or changed
• Classes and methods added, deleted, deprecated, or changed
• Screenshots of new or changed UI, if applicable
• A summary of usage if this is a new feature or change to a public API (this should also be added to relevant documentation once released)
• Any alternative designs or approaches considered

References

Please include relevant links supporting this change such as a:

• support ticket
• community post
• StackOverflow post
• support forum thread

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

• This change adds unit test coverage
• This change adds integration test coverage

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[adamjmcgrath]

Not that is makes much difference, but could you change this to:

import mod from './index.js';

export const { ManagementClient, AuthenticationClient } = mod;
export default { ManagementClient, AuthenticationClient }

(and check it still fixes your issue)

This works for Node 19 and looks a bit simpler - also i don't think we need the doc (I should probably remove this from the other index too)

[adamjmcgrath]

Could you use conditional exports for this, I believe module is the "old" way of specifying esm exports for bundlers, and the standard node way is exports

Suggested change

	"module": "src/index.mjs",
	"exports": {
	"import": "./src/index.mjs",
	"require": "./src/index.js"
	},

(and also check that it resolves your issue - thanks!)

[btakita]

Yes, it makes sense to use exports...however it will require a major version update for this library if you are following semver rules. I went with the more conservative route of adding "module" but if you are willing to push a major version update, then we can switch it to exports.

[adamjmcgrath]

Thanks @btakita - possibly a stupid question - why do you think it would be a breaking change?

[btakita]

I think it has to do with preventing any other entry points besides those defined in "exports". found in https://nodejs.org/api/packages.html#package-entry-points

I suppose that if all of the modules in the package were defined within exports, then it may not be a breaking change. I'm not sure though. I'll look more into an authoritative source on whether it would still be a breaking change if all modules in the package were defined in exports.

[adamjmcgrath]

Ah ok, I didn't know that - let's stick with "module" then

[adamjmcgrath]

Thanks @btakita

[langell]

I'm still having issues with the auth0 package when I deploy to an AWS lambda using serverless framework and webpack.
I'm using ESM syntax to pull in the auth0 package

import { AuthenticationClient } from 'auth0';

This is the error

{ "errorType": "Runtime.ImportModuleError", "errorMessage": "Error: Cannot find module './management'\nRequire stack:\n- /builds/*************/auth-services/user-registration-service/node_modules/auth0/src/index.mjs", "stack": [ "Runtime.ImportModuleError: Error: Cannot find module './management'", "Require stack:", "- *************/auth-services/user-registration-service/node_modules/auth0/src/index.mjs", " at _loadUserApp (file:///var/runtime/index.mjs:996:17)", " at Object.UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1031:21)", " at start (file:///var/runtime/index.mjs:1194:23)", " at file:///var/runtime/index.mjs:1200:1" ] }

[adamjmcgrath]

Hi @langell - we didn't add package exports because this would have been a breaking change.

You probably need to do something like import * as auth0 from 'auth0'; to make it work in environments that require package exports. (we intend to resolve this in the next major)

[langell]

ok I'll give that a try, thanks for the speedy response :-)

[langell]

@adamjmcgrath, do you have a roadmap date for when you will release the package exports?

[adamjmcgrath]

@langell - I don't have a timeline I'm afraid

Although looking at your stacktrace again, I don't think this is the issue as index.mjs is being discovered, the require('./management') bit is failing. If you can reproduce this locally, feel free to share details and I can take a look.

[langell]

@adamjmcgrath, I'll get you the details later today. I will be able to duplicate this locally I think
Thanks!