24 Replies
Wohooo @Ricardo Batista, you just became a Waspeteer level 6!
Hi @Ricardo Batista. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The error message you're seeing indicates that the
User
entity is not defined in your Wasp code. In Wasp, you need to declare a userEntity
for all auth
methods. This field tells Wasp which Entity represents the user.
Here's an example of how you can define the User
entity in your main.wasp
file:
You can add any other fields you want to the user entity. Make sure to also define them in the userSignupFields
field if they need to be set during the sign-up process.
For more information, you can refer to the Wasp documentation on User Entity (https://wasp-lang.dev/docs/auth/social-auth/overview#user-entity).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Ricardo Batista, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?When I do
wasp version
I still get:
what happens when you try to upgrade the version of wasp? do you have any logs of success / failure? I tried to upgrade wasp myself right now and it worked ok
![No description](https://cdn.answeroverflow.com/1263524471059386540/image.png)
Yeah sounds like you are just now using newer version of Wasp, the question is why did you fail to upgrade it / what stopped you.
Damn, so simple @IamIconLiving 🌶 - sorry for not following the guide 🙏
No worries! @martinsos how complex it is to implement an actual version check when running cli and suggest users to update it if it’s not latest?
Weird, now when building with
wasp start
I get
(cc @kapa.ai )Let me check the knowledge base for you. One moment! :books:
----------------------
The error message you're seeing indicates that the
AuthUser
member is not being exported from the wasp/auth/types
module. This could be due to a few reasons:
1. The AuthUser
member is not defined or not exported in the wasp/auth/types
module. You should check the module to ensure that AuthUser
is properly defined and exported.
2. There might be an issue with the path to the wasp/auth/types
module. Make sure that the path is correct and that the module is properly installed.
3. It's also possible that there's a version mismatch or a bug in the Wasp framework. Make sure you're using the latest version of Wasp. If the problem persists, consider reporting the issue on the Wasp GitHub page (https://github.com/wasp-lang/wasp/issues).
As a workaround, you can try cleaning the Wasp build artifacts and reinstalling the dependencies. You can do this by running wasp clean
followed by wasp start
as suggested in a Discord support thread (https://discord.com/channels/686873244791210014/1215750573278629958).
If none of the above solutions work, it would be helpful to have more information about your project setup, such as the version of Wasp you're using and the contents of your wasp/auth/types
module.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Ricardo Batista, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Rename wasp/auth/types to wasp/auth
Spot on!
And now getting:
(sorry to be pasting here these issues, but I am bit lost here)
Those are typescript errors. It looks like that function is defined to return 'Promise<Payload>', but the actual return value of that function is different.
@Ricardo Batista you migt want to check out migratino instructions here: https://wasp-lang.dev/docs/migrate-from-0-13-to-0-14 -> if you are on older verisn of Wasp like 0.12, then you will first want to check 0.12 to 0.13 and only then 0.13 to 0.14
Migration from 0.13.X to 0.14.X | Wasp
This guide only covers the migration from 0.13.X to 0.14.X. If you are migrating from 0.11.X or earlier, please read the migration guide from 0.11.X to 0.12.X first.
Ha @IamIconLiving 🌶 that is actually a great question! The truth is, it is more complex than it should be, in hindsight :D.
The thing is, Wasp parses the whole main.wasp file, and then extracts
app.wasp.version
from that and checks it. If it fails in parsing the file, it will throw parsing error before it ever gets to checking the version. Which looking back at it was a bad design, as you will get an error like unknown field app.db
instead of getting wrong Wasp version, should be X but is Y
.
I see a couple of ways to avoid this out of the bat:
1. Take out specification of wasp version from the main.wasp file and have it somewhere else, maybe in additional wasp.version file or something like that. Could be in package.json in theory but I don't like that idea, I don't want package.json to act as a top level config file for the whole project, just for the JS part (which is most of the project but that might change in some ways in the future with polyglot stuff).
2. Have some kind of "pre-parsing" step that would parse main.wasp only for the version, ignoring then rest. This is probably the way to go, shouldn't be super hard, but is also not trivial but will take a couple of hours to properly implement, test and so on.
3. Simialr to (2), but istead of "pre-parsing", we inject additional piece of logic at the early phases of parsing (so once we have AST, but before CST), that check for version.
So I would probably go for (3), but taking into accoutn that TS SDK is coming, and that we might drop Wasp DSL if TS SDK works well, it feels like it is best to just not spent time on it since it will anyway likely go into trash in a couple of months.Oh, sounds super complex. I was thinking for something way more simpler - whenever user runs wasp CLI (like wasp run), it quickly checks if user has latest cli version, and if not - spits out a message advising to update it with a url (while continuing its operation and starting up all the servers etc so it’s a non-disruptive operation). It might take a small hit on start up performance of wasp run I guess, but there are ways to minimize the damage