Improve experience regarding common mistakes/errors when using Wasp

[Martinsos]

Related Discord convo: https://discord.com/channels/686873244791210014/943092165964349500/1229359737322213386 .

There is a whole suite of common mistakes that people get into while trying to use Wasp, especially for the first time, like not having Docker installed, importing server imports in client and vice versa, not setting up env variables, hitting limit on number of files watched, ... .

For a lot of those, we don't have nice error messages -> sometimes they are kind of on spot but overly verbose, while sometimes they are just completely unconnected, e.g. if you try to import non-existing js/ts file in main.wasp, you get "router.js error", which is hard to figure out what it means, or if you import server file in client code you get process not found which is also confusing.

So, what we want to do is improve the experience around these common mistakes!
There are multiple ways we can do that:

1. Target each one of these mistakes and improve experience for it.
2. Have some kind of general mechanism that helps figuring out these mistakes related to wrong usage / setup.

Now, for both of these, we can either try to improve error messages, or we can try to improve the Wasp design itself so it is much harder to make a mistake (e.g. don't allow them at all to import client code in server code). So, better error messages, or better design.

List of specific issues we know about so far:

• Having wrong version of Node: OK, we solved this one recently.
• Importing server code into the client code and vice versa results in obscure errors (e.g. process not found).
• Importing non-existent JS/TS file as a page from Wasp results in confusing "router" error messages.
  Related: Can we help users distinguish their client and server JS files (and also detect wrong imports in main.wasp)? #1741 .
• ... -> add more here as we learn about them! There are certainly more.

Ideas for general improvement of experience of setup-related mistakes:

• Implement wasp doctor that analyzes state of the project: Implement wasp doctor command #1970 .

[codexsmith]

Bug Report for specific issues

• Docker Configuration When using the ai-generated template I was getting a 404 from openai's API. I thought it might be a proxy issue, but I was able to curl the API. The issue was docker was not properly configured for my environment. I'm running WSL2 Ubuntu-22.04 and needed to install docker in WSL, enable docker's WSL integration on the host machine, and ensure Docker was running on the host. It's certainly outside the scope of WASP to ensure Docker is configured correctly for such an environment, but an error message indicating Docker is being used would have expedited the fix.

Idea for improvement of experience of setup related mistakes

• Template generation & progress The process took quite a long time for me. (I've discovered this was likely due to WSL2 and how I had configured the filesystem.) I'm not sure, hours, so long that I thought it had failed because the message said it should take 90 seconds. I could see it had made some API requests so I let it work and just went to bed. The next morning I was happy to see that it had succeeded. It only cost about $1.50, made 17 requests, and used 42k tokens with the options Model: [3] gpt-4 and Temp: [2] conventional. Could we improve the progress output of the templating engine? Something as simple as "API Requests Remaining" would go a long way.

[Martinsos]

Bug Report for specific issues

• Docker Configuration When using the ai-generated template I was getting a 404 from openai's API. I thought it might be a proxy issue, but I was able to curl the API. The issue was docker was not properly configured for my environment. I'm running WSL2 Ubuntu-22.04 and needed to install docker in WSL, enable docker's WSL integration on the host machine, and ensure Docker was running on the host. It's certainly outside the scope of WASP to ensure Docker is configured correctly for such an environment, but an error message indicating Docker is being used would have expedited the fix.

Idea for improvement of experience of setup related mistakes

• Template generation & progress The process took quite a long time for me. (I've discovered this was likely due to WSL2 and how I had configured the filesystem.) I'm not sure, hours, so long that I thought it had failed because the message said it should take 90 seconds. I could see it had made some API requests so I let it work and just went to bed. The next morning I was happy to see that it had succeeded. It only cost about $1.50, made 17 requests, and used 42k tokens with the options Model: [3] gpt-4 and Temp: [2] conventional. Could we improve the progress output of the templating engine? Something as simple as "API Requests Remaining" would go a long way.

Thakns for the feedback!

So in the first case, your Docker was misconfigured. If docker was missing, you would get an error, so that should already be happening, but it is quite harder for us to figure out if it is somehow misconfigured I am afraid. Would be great if we can be samrter about this and catch some common issues, but it is a bit too much out of the way for us with our current capacity. Still, will keep it in mind.

AI generation -> interesting! So usually it does really take like 90 seconds or less. I wonder if it was an issue from the OpenAI side, maybe they were overloaded and requests were taking a long time? Hours sounds impossible hm! I wonder if this is repeatable for you or it was an one-off thing, an outlier.
That is an interesting idea, to maybe give a bit of an idea on how long stuff will take. But taht is also why we had that 90 seconds message :D, and it is normally correct!