P1 bug in wasp causing insanity in developer. Please isolate and fix. :-)
I just spent a day tracking down a problem, which manifests itself in a very unusual way,.
Adding this line of code (to a server-side .js file):
import { subtractCredits } from 'wasp/server/operations'
This causes relative imports to stop working, and you can't fix the build by fixing them (obvious now, not so a few hours ago). The broken import is the only error emitted during the build, so the tools leave you in a hole. Git archaeology FTW.
-------
In main.wasp we have defined subtractCredits as follows:
action subtractCredits {
fn: import { subtractCredits } from "@src/payment/creditManagement.js",
entities: [User]
}
and in src/payment/creditManagement.ts we have a "export const subtractCredits = async (args, context) => { ... }.
Not 100% certain what's wrong here. This code is server side as stated above. We call it successfully from client. This is the first time I tried to call it from server, and not only does it not work, it silently murders the build. 😦 [EDIT: Just saw the mismatch between .js and .ts in the import/actual filetype, unfortunately that was not the cause of the problem as the imports still break after fixing...]
22 Replies
Hi @Conspyre. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
I'm sorry to hear about the issue you're facing. Based on the information you've provided and the knowledge sources I have, it seems like there might be a misunderstanding in how to import actions on the server side.
In Wasp, when you're importing actions on the server, you should import them from
wasp/server/operations and not wasp/client/operations. This is because the server and client have different contexts and requirements. When calling an action/query imported from wasp/server/operations, you need to pass a context that contains the user info (without the entities). If your query doesn't require auth, you should be able to pass an empty object source (https://discord.com/channels/686873244791210014/1218567315185209464).
However, there seems to be an issue with the Wasp documentation that incorrectly states that you can import actions from wasp/client/operations on the server side. This is a mistake and the documentation needs to be updated source (https://github.com/wasp-lang/wasp/issues/1909).
As for the issue with relative imports stopping to work, it's hard to say without more information. There have been issues reported with inconsistent import extensions in both .wasp file and in JS files, which might be related to your problem source (https://github.com/wasp-lang/wasp/issues/1363).
I would recommend checking your import statements and ensuring that you're importing from the correct location (wasp/server/operations for server-side code). If the issue persists, it might be a good idea to report it on the Wasp GitHub issues page for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?@kapa.ai in my read of the documentation, the docs correctly state to import from 'wasp/server/operations', and I am doing the same in my code. Believe you are hallucinating. Sorry my friend. 😦
The "broken relative imports" seems to be an internal bug, and some problem with my code may be triggering that bug, in my opinion, but I don't know. 😦
Will gather more data and report on Github.
Let me check the knowledge base for you. One moment! :books:
----------------------
I apologize for any confusion. If you're already importing from
wasp/server/operations as per the documentation and still encountering issues, it does seem like there might be a bug.
The issue with broken relative imports could be related to a known issue where the server requires extensions in imports, and there are even more considerations regarding if it is .js or .ts. This has been reported to cause confusion and could potentially be related to the problem you're experiencing source (https://github.com/wasp-lang/wasp/issues/1363).
Gathering more data and reporting the issue on the Wasp GitHub issues page is a good next step. The Wasp team is quite responsive and should be able to provide further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?Interesting re>that GitHub issue but it seems not to be relevant. If we remove that import / do not call that piece of code in that particular server function, the "relative import broken" issoe goes away entirely. Simply adding that one line - the import - is triggering the behavior. I just don't know how to distil this entire project down to a reproducible issue. @kapa.ai
Let me check the knowledge base for you. One moment! :books:
----------------------
I understand your concern. It's indeed strange that adding a single import line is causing such behavior.
Here are a few steps you could take to isolate the issue:
1. Check the imported module: Ensure that the
subtractCredits function in @src/payment/creditManagement.js doesn't have any issues or dependencies that could be causing the problem.
2. Simplify the function: Try to simplify the subtractCredits function to the bare minimum, removing any other imports or dependencies, and see if the issue persists.
3. Create a minimal reproducible example: If possible, try to create a new, minimal Wasp project where you only add similar action and try to import it in the same way. This could help you identify if the issue is specific to your current project or a more general issue with Wasp.
4. Check for updates or known issues: Ensure you're using the latest version of Wasp and check the Wasp GitHub issues page (https://github.com/wasp-lang/wasp/issues) for any similar reported problems.
If none of these steps help, I would recommend reporting this issue on the Wasp GitHub page with as much detail as possible. Even if you can't provide a minimal reproducible example, providing the details of your current setup, the exact error messages, and the steps you've taken to debug could be helpful for the Wasp team to investigate the issue.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?@kapa.ai I found the first user error, in the API declaration I had mistakenly put a .js extension for the file, which was itself a .ts file.
Correcting this error did not fix the issue. Uncommenting the import of this action breaks the build.
Are there any issues in the knowledge base or on Github regarding API actions and typescript files specifically?
Let me check the knowledge base for you. One moment! :books:
----------------------
Based on the knowledge sources provided, there are several issues related to TypeScript files in Wasp:
1. Issue #835 (https://github.com/wasp-lang/wasp/issues/835): This open issue discusses supporting custom TypeScript configuration in Wasp. It mentions that Wasp 0.12.0 shifted the goals for this issue, but the rest is still relevant.
2. Issue #910 (https://github.com/wasp-lang/wasp/issues/910): This closed issue discusses full-stack type support for Queries and Actions in Wasp. It mentions the goal of having users define everything about a Query or an Action once, probably inside the Wasp file.
3. Issue #589 (https://github.com/wasp-lang/wasp/issues/589): This closed issue discusses supporting user code written in TypeScript and TSX. It suggests finding a way to provide TypeScript support for user-defined code.
4. Issue #1430 (https://github.com/wasp-lang/wasp/issues/1430): This closed issue discusses figuring out Wasp's
tsconfig story for the restructuring. It mentions deciding on what to put in the user's TS config file, and how to reuse it in .wasp/out/server and .wasp/out/web-app.
5. Issue #1066 (https://github.com/wasp-lang/wasp/issues/1066): This closed issue discusses adding a TypeScript tutorial to Wasp's documentation.
While these issues provide some context about TypeScript support in Wasp, none of them seem to directly address the specific issue you're facing with importing an action from a TypeScript file. I would recommend reporting this issue on the Wasp GitHub page for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?@kapa.ai update: I can change the import, pulling the function directly from the source file instead of from the wasp/server/operations wrapper, the build does not break, the birds resume singing, and the chemtrail fog clears from the skies. But we aren't using wasp actions framework any more. 😦
Let me check the knowledge base for you. One moment! :books:
----------------------
I understand your concern. Importing the function directly from the source file instead of from
wasp/server/operations does bypass the Wasp actions framework, which is not ideal.
The Wasp actions framework provides a structured way to handle server-side operations and ensures that the necessary context is passed to your actions. Bypassing it could lead to unexpected behavior or missing functionality.
Based on the knowledge sources, there's a discussion about this exact scenario on a Github issue (https://github.com/wasp-lang/wasp/issues/1909). It mentions that users can import actions directly from their files, but they have to construct the context completely on their own. If they import it via wasp/server/operations, they don't have to construct it completely on their own, but need to pass just user to the context and the rest will be added.
It's recommended to use the Wasp actions framework for server-side operations. If you're facing issues with it, it would be best to report this on the Wasp GitHub issues page for further assistance. The Wasp team is quite responsive and should be able to help you resolve the issue.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?@sodic another one for you for Monday
Yup thanks @Conspyre , our local expert for operation imports, @sodic , will give this a look 😄
Hey @Conspyre, I answered here: https://github.com/wasp-lang/wasp/issues/2271#issuecomment-2337775531
I'm guessnig that's you 🙂
TL;DR we need more info
GitHub
Adding an import from wasp/server/operations on server side code is...
Describe the bug This is kind of a weird problem. It's probably user error but it triggers a bug that breaks the build in a bad way. To Reproduce I added this exact line of code to my server si...
That was me. 🙂 TL;dr I suspect something dumb or rulebreaking vis a vis schema changes, but no longer can get back to that state. @sodic
Ok, so just to be clear, the problem is gone now?
@sodic Yes. The problem is gone if I import that Action directly. If I import it from "wasp/server/operations", it still breaks. Sorry if I wasn't more clear, still learning. 🙂
How bad of trouble am I getting into by going around the Wasp system to commit rather vital things to the database?