auth0/node-auth0

esbuild/vite: ReferenceError: module is not defined

btakita opened this issue · 4 comments

btakita commented

Checklist

  • I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
  • I have looked into the API documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Description

When importing 'auth0' in Vite, the following error occurs:

ReferenceError: module is not defined
    at /home/brian/project/node_modules/.pnpm/auth0@3.4.0/node_modules/auth0/src/index.js:8:1
    at instantiateModule (file:///home/brian/project/node_modules/.pnpm/vite@4.3.5/node_modules/vite/dist/node/chunks/dep-934dbc7c.js:54360:15)

Reproduction

  1. Vite project with auth0
  2. import { ManagementClient } from 'auth0'

Additional context

Vite requires valid esm modules, meaning commonjs modules cannot be imported.

The following must be used with nodejs for this to be valid ESM.

import { createRequire } from 'module'
const require = createRequire(import.meta.url)
require('./path/to/common-js-module.js')

Note that webpack & rollup imports are not valid esm but a temporary hybrid.

node-auth0 version

v3.4.0

Node.js version

20.1.0

btakita commented

Looks like there's an issue with createRequire & bundlers.

#828

Looks like webpack supports createRequire

https://webpack.js.org/configuration/externals/#externalstypenode-commonjs

while rollupjs does not support nodejs createRequire

rollup/rollup#4597
rollup/rollup#4274

yet does support deno createRequire

https://rollupjs.org/tools/#deno

esbuild makes createRequire a requirement as it supports only valid ESM & will not import commonjs using the import statement.

Edit:

I'm looking more into solutions. There is the deasync library, which would enable synchronous imports from cjs modules. If this library were written in esm with a cjs shim, then we can use that approach.

If we don't want something like deasync as a dependency, we could create a cjs api shim. There may be a clever way to utilize the Proxy object, perhaps by enqueueing synchronous calls & importing the ESM in one of the async functions.

A cjs shim approach will fix the ESM issues for all bundlers with some added complexity in the cjs shim itself.

---- Edit 2

A simpler solution would be adding a separate exports to support both the import cjs interop & the createRequire cjs interop.

btakita commented

For now, esbuild/vite projects can use createRequire to load the cjs version of this library.

adamjmcgrath commented

Thanks for raising this @btakita

We're currently doing a rewrite of this library to ESM for v4 which should resolve this issue. For now, in the current v3 version I suggest using the workaround you've described (to load the cjs version using createRequire) - unless you have a better suggestion for v3?

Looks like webpack supports createRequire

That's odd, because most of the reports with the createRequire version of our index.mjs were with Webpack #783 (comment)

adamjmcgrath commented

We've released v4 Beta which should have full support for ESM (and CJS)

For bundling v3 within esbuild/vite projects we recommend using the workaround described in #832 (comment)

Closing this thread in favour of #859

  • ❤️2