Error building after migrating Wasp to 0.12
I am getting the below error after migrating Wasp to 0.12, I am using NodeJS 20. Below is the error, how do I fix this?
30 Replies
I am also getting:
Uncaught ReferenceError: process is not defined This used to work, it started after migrating to latest Wasp versionit seems like
globalThis has changed. Maybe @Filip can help here
which file is this error occuring in? it seems like its not able to access your .env.server file. Is it in the correct place?My guess is that the part of the code that was previously executed in the server context is now executed in the client context.
@Godspeed1337 Can you tell us in which files do the errors happen and how you se those files (who imports them)?
@Filip The error is coming from
config.ts inside the sdk folder.
.env.server is inside the app folder, I am using open-saas.did you modify the contents of the
.wasp folder, i.e. the sdk folder?No, I didnt modify the content of .wasp folder, I have executed
wasp clean and did a fresh wasp start stil same error.This was the error from the config.ts file from my browser.
weird. what happens if you add
PORT=3001 to your .env.server file? if that fixes it, then somehow your app is picking up that you're not in the development environment.
althought that shouldn't be the issue probably. any ideas @Filip @martinsos ?Almost like the app is not building properly, I added the PORT to
.env.server file, but the app still had the error in browser console Is there a specific Node version that Wasp works with? I have tried version 19 and 20, same issue persisted.Wohooo @Godspeed1337, you just became a Waspeteer level 1!
yeah so as sodic said before, for some reason the server files are being served in the browser
which shouldn't be happening
hence why
process isn't available
if you search your code for any TODOs, do you find one that has to do with the recent migration?
like in app/src/server/auth/setUsername.ts for example?hmm. can you share your
main.wasp file?
somewhere there is server code being executed in the client
if we can find where that's happening we can fix the problemIf you are getting this error in the browser, this means something that should be only used on server is being used on the client. Can you check your imports and make sure you are not importing anything from
wasp/server/* on the client?It would likely help if you could share more info @Godspeed1337 . Ideal would be a reproducible example you can share with us, that we can try running ourselves. If that is too hard to obtain, then maybe sharing some specfiic of your app -> you said it is built with open saas, anything else you can share?
Regarding an error -> any more error logs around it?
@vince-wasp did old open-saas directly access some auth primitives anywhere? Maybe these need special care when migrating to wasp 0.12?
the only thing i can think of is to check for
@wasp/shared
and change it to be a relative import, e.g.
but, yes, if you can share a github repo with us that would be great. then we can try it out outrseves @Godspeed1337@Godspeed1337 I have an idea what might be the problem.
If you imported
@wasp/config on the frontend before the migration, our migration tool probably changed it to wasp/server/config (because Wasp never officially supported importing the config on the client, it was probably working by accident 😄 )
Can you check whether that happened (more precisely, whether one of your frontend files imports wasp/server/config)?Yip!! @Filip @Vinny (@Wasp) I just confirmed the migration tool changed the config to import from server file, I saw
import { config } from 'wasp/server'; Thanks you guys!oh nice! glad we got that fixed.
what were you importing the config for?
I was getting the apiUrl from the config file in the previous version, the new version somehow doesn't have apiUrl anymore.
The only part I am yet to solve is this node:crypto error, I am getting this in my terminal.
Looks like a polyfill for node 18, the error only shows up on Node > 18.18.0
@martinsos @Filip this is a polyfill suggested by Lucia's docs for Node.js < 18, I didn't expect this cause issues with Node.js 20 😢
https://lucia-auth.com/getting-started/
Lucia
Getting started
Lucia is an open source auth library that abstracts away the complexity of handling sessions.
@Godspeed1337 could you stick to Node.js 18 until we fix this? 🙂
Here's an issue for this: https://github.com/wasp-lang/wasp/issues/1833
GitHub
Web Crypto API polyfill breaks Wasp when used Node.js 20 · Issue #1...
WarningWasp doesn't work correctly with Node.js 20 This was reported on Discord File: /app/.wasp/out/server/src/polyfill.ts:7 globalThis.crypto = webcrypto as Crypto; TypeError: Cannot set prop...
Ok, we jjst released wasp 0.12.2 which should fix this!
Try updating with
curl -sSL https://get.wasp-lang.dev/installer.sh | sh -s and let us know if the error persists@miho @Vinny (@Wasp) Do you have any idea what could cause the following error when running
wasp start I am using the latest version of wasp.
wasp-bin: app/src/client/icons/[some files]: openFile: resource exhausted (Too many open files)
I had to use ulimit -n 10000 to bypass that error.Wohooo @Godspeed1337, you just became a Waspeteer level 2!
Hmmm, good to know @Godspeed1337
@martinsos @Filip are we maybe watching
node_modules?@Godspeed1337 oh that is intersting! @miho we do not want to watch
node_modules, but if we were watching it, this would explain the issue.
Check the image for our watching logic.
So we are watching all files at the top level (but not going into any directories, so not recursively), and then we watch recursively (so all depths) the directories src/ and public/.
That said, we do have Wasp watching your source files, and then we also have nodemon watching the generated server files, and we also have vite watching generated client files. Those processes are spawned by the wasp start, so maybe it all counts together toward its opened files limit? And maybe that sum indeed is over 1024 or wathever is the default?
====================================
Ok I did the following: I ran
wasp start for a simple TodoApp genreated with Wasp AI.
Then, I ran lsof -p <pid> | wc -l for each of the processes spawned by wasp start, to see how much files is each one of them consuming.
For me, numbers looked okish, although frontend was a bit suspicious (vite), with a pretty high number of files compared to the others.
@Godspeed1337 could you do the same thing for your Wasp app? Then we can see exactly who the culprit is, this would help a lot.