Auth0-spa-js: auth0_spa_js_1.default is not a function

[Dig-Doug]

Hi, I'm trying to use the auth0 library in my project but I'm getting an error:

ts_scripts.js?v=1563805379409:34261 ERROR Error: Uncaught (in promise): TypeError: auth0_spa_js_1.default is not a function
TypeError: auth0_spa_js_1.default is not a function

I've seen some similiar issues, #60, #45, but their setups are a bit different and I've tried the suggested tsconfig fixes and I couldn't get them to work.

My project uses a setup similar to the angular-bazel-example, so I've created a repro of the problem using it. Steps are below.

cd /tmp
git clone https://github.com/Dig-Doug/angular-bazel-example.git
cd angular-bazel-example
git checkout 8fa48dc1b977c435178aa5bfc1f9d601ed15f5b7
yarn install
npx bazel run //src:devserver

# It should say "Server listening on XXX"

The auth service from the example is in src/app/auth/ and I've tried to use the service in src/app.component.ts.

When you connect to the local server, the page will load and lots of messages will be printed to the console. Make sure you scroll to the top, the error message is there.

I think the problem has something to do with how the auth0 library is being exported or imported. Looking at the generated code, auth.service.js (note JS), it tries to access the library with:

this.auth0Client = yield auth0_spa_js_1.default(this.config);

In my main project I use lots of other 3rd party libraries, e.g. immutable, three, without issue so it's not an issue with loading libraries in general.

Please let me know if you need any more info.

Thanks!

[necramirez]

We have the same problem. We can't change our tsconfig as the other issues say because doing that breaks our build.

[luisrudge]

ok, found the issue, although I can't really say why TS works like this 😬

LOOOOTS of other libraries have the same issue: https://www.google.com/search?q=typescript+default+is+not+a+function

https://github.com/iamkun/dayjs/issues/475#issuecomment-483792717

Ahh actually it was a bit more complicated I'm realizing then what I wrote. Basically when you have a library compiling with tsconfig allowSyntheticDefaultImports and then a consuming application that does not use that setting, we got that error. Both the library and consuming application had dayjs as dependencies.

So, the issue here is: since we're using allowSyntheticDefaultImports: true in our library, all the consumers of our library have to use it as well. This totally sucks because your app might need that flag set to false to work properly.

In bazel's case, simply setting "esModuleInterop": true in tsconfig.json makes it work.

@necramirez can you check if this works for you as well?

[Dig-Doug]

That works, thanks!

Not sure if you want to stop using allowSyntheticDefaultImports and track with this issue -- if not, feel free to close, the esModuleInterop change works for me.

[luisrudge]

Yeah, esModuleInterop was actually created to "fix" this whole situation with allowSyntheticDefaultImports. It still sucks that this is a requirement for some people and I think the actual solution is stop using default exports. For now, I'll add an entry to our FAQ to make sure people know what to do when facing this issue. Thanks for the patience and your help figuring this out! 🎉

[necramirez]

Just want to say that esModuleInterop: true also fixed it for us.