supabase
supabase copied to clipboard
Module failing to load on Nuxt 3.0.0-rc.4
Version
@nuxtjs/supabase: 0.1.17 nuxt: 3.0.0-rc.4
Reproduction Link
https://github.com/gregmulvaney/supabase_error
Steps to reproduce
- Fresh Nuxt 3 app generated with Nuxi
- Install @nuxtjs/supabase
- Add entry to Nuxt build modules
- Run nuxt dev
What is Expected?
It works
What is actually happening?
While Vite does start up, as soon as you attempt to load the site in a browser it hangs and then eventually returns a 503. Console outputs
Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension. (Use node --trace-warnings ...to show where the warning was created)
Removing @nuxtjs/supabase from the modules list fixes this error.
Update
I am amble to use the module if I run nuxt build
and nuxt preview
. Still does not work with nuxt dev
Same issue here
I've found a temporary fix in disabling SSR in my Nuxt Config.
Same here tried "type": "module" in the package.json
but didn't help at all. As this was happening after not touching an existing project for a while it was a bit harder to track down. --trace-warnings
didn't help either.
I've found a temporary fix in disabling SSR in my Nuxt Config.
Works for me in dev, broke production
this error is pretty weird, I was just using "@nuxtjs/supabase": "^0.1.4" or "@nuxtjs/supabase": "^0.1.17" a day or two ago and it worked without any problems following the nuxt's youtube channel tutorial, but sudenly it stopped working anymore with this error, I even thought it was something else and tried to uninstall other packages one by one testing, is there any other version working ?
After digging a lot in sub dependencies, I finally found the guilty. I'll soon provide a release to fix it. To fix it temporary, can you try to add a resolutions
field in your package.json
with:
"resolutions": {
"@supabase/postgrest-js": "0.37.3"
}
For me that solution didnt work since my supabase implementation was via @nuxtjs/supabase. What helped in this case was to add **/
in front of the package name:
"resolutions": {
"**/@supabase/postgrest-js": "0.37.3"
},
I'm curious as to why this could fail without version bump. Shouldnt minor changes of dependencies also be reflected into minor changes of the main package? This could theoretically break production builds or am I missing something?
With all due respect btw.. I really like Supabase!
Thanks for making the issue and reproducing with the latest working version. I've managed to find the fix but worth sharing the story.
First thing first, in order to find more information about the cause of the error, as the Node.js message tells, we can use --trace-warnings
:
$ node --trace-warnings node_modules/.bin/nuxi dev
/home/pooya/tmp/supabase_error/node_modules/@supabase/postgrest-js/dist/module/lib/types.js:10
export class PostgrestBuilder {
^^^^^^
SyntaxError: Unexpected token 'export'
This means our dev bundle is importing an invalid ESM module from @supabase/postgrest-js
. Read more in v3 Docs about invalid ESM modules.
There are two entries to inspect:
-
.nuxt/dev/index.mjs
(nitro bundle) -
.nuxt/server/server.mjs
(vite bundle for nuxt app) <-- issue is here
Searching for import
and import()
, there is the problematic import line in vite bundle:
import("file:///home/pooya/tmp/supabase_error/node_modules/@supabase/postgrest-js/dist/module/lib/types.js")
The issue is that @supabase/postgreest-js
has filed, is using ESM syntax bu not comply with what Node.js expecting for ESM code to use .mjs
extension or type: "module"
in nearest package.json. Now with Nuxt 3, we took some smart ideas to automatically detect this situation and inline the dependency using vite or rollup that can handle such mixed syntax. (unjs/externality and unjs/mlly#isValidNodeImport).
This was automatically working until [email protected]
because types.js had an import statement but in 0.37.4
that import was removed and regex in mlly wasn't enough to cover only export class PostgrestBuilder
So how is the fix and steps:
- [x] Supabase module should explicitly add all esm-incompatible
@supabase/
packages explicitly to theebuild.transpile
step to avoid such regressions when automated detector doesn't works. - [x] Improving mlly syntax detection to detect
export class
and categorize as ESM (https://github.com/unjs/mlly/commit/896c8a7dd087d041ffb29a00065a4f71d62ed249) - [ ] Ask
@supabase
libraries to fix ESM issue. Solution is as easy as adding a package.json to thedist/module/
withtype: module
or (much better) use.mjs
/.cjs
syntax.
You can now remove the temporary fix, this issue should be fixed on v0.1.18
thanks to #55 and should also be fixed on other version thanks to mlly update. Thanks @pi0 !
You can now remove the temporary fix, this issue should be fixed on
v0.1.18
thanks to #55 and should also be fixed on other version thanks to mlly update. Thanks @pi0 !
Thank you, this resolved the issue for me.
Hey folks! I maintain @supabase/postgrest-js
.
Curious why the bundler is picking up dist/module/index.js
instead of dist/main/index.js
- the Nuxt docs mentions that Node.js will pick up "module"
in package.json
, but the Node.js docs says otherwise:
Node.js ignored (and still ignores) the top-level "module" field
So up til now we've been expecting Node.js to pick up dist/main/index.js
(which uses CommonJS) and non-Node.js contexts to use dist/module/index.js
(which uses ESM).
I'm not sure what's the best path forward here, but if anyone knows of an isomorphic JS library that handles all the contexts gracefully (e.g. Node.js, browser, WebWorker, serverless, Deno), let me know!
Thanks for reaching out @soedirgo <3 Would be definitely happy to help improve isomorphic builds. Also indeed it is strange but at same time makes sense to pick ESM syntax over CJS using module
field when available. If there is an exports
field, it will be picked... (reopen was accident :D)
If there is an exports field, it will be picked...
Interesting - I'll test it out on the repro link above.
Also please check out unjs/unbuild. It is specifically designed for ESM friendly libs.