auth0/auth0-vue

ESM Support. Wrong package exports. no .mjs file extension used.

awacode21 opened this issue · 22 comments

Describe the problem

Within esm projects we cannot import '@auth0/auth0-vue' cause its commonjs.
i had a look on whats delivered by that package:
Bildschirmfoto 2022-10-21 um 13 04 17
Bildschirmfoto 2022-10-21 um 13 04 08
there are main and module configurations with wrong file endings. instead i guess you need in package.json export definitions for require and import based on .js and .mjs endings.

That results in errors:
Bildschirmfoto 2022-10-21 um 13 02 56

Currently it seems the package is not esm ready. So i would like to ask to fix this as we really need it in our project urgently.

What was the expected behavior?

esm package import to work as expected

Environment

  • **Version of auth0-vue used: ^1.0.2
  • **Version of vue used: ^3.2.37
  • **Which browsers have you tested in? Chrome, but it is browser independant
  • **Other modules/plugins/libraries that might be involved: "vite": "^3.1.8"

and when trying to import this instead '@auth0/auth0-vue/dist/auth0-vue.production.esm.js' it is not working, i get errors like:
Bildschirmfoto 2022-10-21 um 13 33 43

this is really a massive blocker on our project

Thanks for reaching out. I am a bit confused by the first screenshot of the error you shared.
It's not mentioning our SDK, it's mentioning Swiper?

Are you sure the original error is caused by our SDK? If so, can you show the error you have before changing the import to @auth0/auth0-vue/dist/auth0-vue.production.esm.js, as per your second screenshot.

@frederikprijck oh sorry, this was the wrong screenshot!!! i updated it to the right one. forget about swiper here, this was a wrong upload of mine

Thanks, have you tried doing what it asks you to do?

import pkg from "@auth0/auth0-vue";
const {AUTH0_INJECTION_KEY} = pkg;

Does that work ?

Yes, when i do it that way it complains with the following error as you are not providing a default export
Bildschirmfoto 2022-10-21 um 14 00 54

Ok thanks, any chance you have a small Vue project to reproduce this so we can have a look?

i could create a reproduction on stackblitz, but as i am working on a client project i for sure should not share on stackblitz the domain, audience and client id. Are there somekind of dummy mek accounts which i can use for?

A stackblitz would be best, or a small github project that I can look at.

I just created a new Vue project using vite that has type set to module, and I can import our SDK fine:
image

Are there somekind of dummy mek accounts which i can use for?

You can create your own application on auth0.com for testing, or just leave those values blank in the stackblitz/project.

Were you also able to build and preview this? Because for me it was complaining in the browser

Yes, the console even outputs the correct symbol for the imported AUTH0_INJECTION_KEY:

image

I'll prepare a reproduction on stackblitz

@frederikprijck quick question.. i created a free account. Where do i get the information for 'audience' from?

Audience is an optional field and should only be relevant once you have imported the library, but since importing is the issue here, you can forget about audience for now.

Same for domain and client id. You dont need that info to import our SDK, only to actually use it. But you can't use it if you can't import it.

@frederikprijck i have a running reproduction here: https://stackblitz.com/edit/vitejs-vite-lncyzq?file=package.json&terminal=build

Vite 3 with SSR / Vue 3 / Auth0

Thanks, I will need to look into it.

However, the fact that it worked without SSR but using ESM, makes me believe it should work with ESM. Curious if there is something about the SSR part of it that's causing it.

Thank you for helping me. I really appreciate it.
Yes i am also scratching my head why it works without SSR but not with SSR.

I tried your reproduction locally, and was able to make it work when making the following changes to the package.json from our SDK:

-"main": "dist/lib/auth0-vue.cjs.js",
+"main": "dist/auth0-vue.production.esm.js",
"types": "dist/typings/index.d.ts",
"module": "dist/auth0-vue.production.esm.js",
+"type": "module",

What this means is that when using Vite SSR, it relies on the main value from the package.json, as well as the type value. As our type is set to commonjs, vite will say it's a commonjs package. Even when setting type to module, vite will complain because it tries to use the main bundle, which is common js.

As we can't set our main to ESM, I am not sure there is much we can do from our side. But open to any improvement we can do without breaking existing users.

Having said that, here is a fork of your StackBlitz that works, all you need to do is add the following to your vite config:

ssr: {
    noExternal: ['@auth0/auth0-vue']
}

This should remove the error. Would that work for you?

i think that he always loads commonjs is related to the used file endings...
*.js fallbacks to commonjs... whereas with *.mjs it knows that it is esm... but as both of your files are using *.js he always thinks this is common.js.

i also know/recognized on other packages that when there are different export types, that they removed main/module from packages json and replaced by export definition. something like:

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

maybe that helps?

ssr: {
    noExternal: ['@auth0/auth0-vue']
}

worksaround it for now for me. But i think your cjs/mjs implementation is still not right and needs to be worked on.

As the workaround works, and this is the first time this issue has been raised, we might want to leave things as they are.

If you do believe we need to make changes to our setup to support ESM in a better way without breaking current users, we are always open to that. Feel free to open a PR and I am happy to review it.

Closing this for now.

Seems like "workaround" not fully working... so it worked for the import.. but then when using the library.. when building and running for production i get other errors related to it:

Bildschirmfoto 2022-10-25 um 19 13 25

I dont think I understand what I am looking at, where is this coming from?

Probably makes sense to ensure the reproduction sample has the same error so we can look into it.