CORS middleware wasp generate bug
Was having a CORS issue so I did what one of the guides said and added.
// main.wasp
server: {
setupFn: import setup from "@src/serverSetup",
middlewareConfigFn: import { serverMiddlewareFn } from "@src/serverSetup"
},
//src/serverSetup
import cors from 'cors'
import { config } from 'wasp/server'
export const serverMiddlewareFn = (middlewareConfig: any) => {
middlewareConfig.set('cors', cors({ origin: [config.frontendUrl, 'https:rehouzd.com'] }))
return middlewareConfig
}
However, when recompiling wasp gave this issue:
[!] RollupError: src/server.ts (6:7): "default" is not exported by "../../../src/serverSetup.ts", imported by "src/server.ts".
So I went into the generated:
/app/.wasp/out/server/src/server.ts
and noticed it was importing like this:
import setup from '../../../../src/serverSetup'
To fix the issue I updated my serverSetup to have a default export and it fixed the issue:
import cors from 'cors'
import { config } from 'wasp/server'
const serverMiddlewareFn = (middlewareConfig: any) => {
middlewareConfig.set('cors', cors({ origin: [config.frontendUrl, 'https:rehouzd.com'] }))
return middlewareConfig
}
export default serverMiddlewareFn;
Looks like at least for this file generation wasp was expecting default export syntax instead of just export const. Feel like this could be an issue for others. Thoughts?4 Replies
Hi @CupOfJoe. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Thank you for bringing this issue to our attention. You're right, this could indeed be confusing for other users. Let's break down what's happening and provide some context.
The issue you encountered is related to how Wasp handles imports and exports. Currently, there's an ongoing discussion within the Wasp community about whether to use default exports or named exports.
According to the Github issue on export syntax considerations, Wasp currently uses and recommends the default exports approach in its generated code and documentation. However, there's a debate about potentially moving towards named exports in the future due to various advantages they offer.
Your experience highlights a discrepancy between the documentation and the actual implementation. The documentation on customizing global middleware shows an example using named exports, which is what you initially tried:
However, as you discovered, the generated code expects a default export:
This inconsistency is likely a bug or oversight in the documentation or code generation process.
To address this, you could:
1. Continue using the default export as you've done, which solves the immediate problem.
2. Report this issue to the Wasp team so they can update either the documentation or the code generation to be consistent.
For now, the safest approach is to use default exports for the
serverMiddlewareFn as you've done in your fix.
It's worth noting that the Wasp team is aware of these inconsistencies and is working on improving the situation. As mentioned in a comment on the syntax considerations issue, they plan to make changes and update the docs as they encounter these parts of the code.
Thank you for sharing this experience. It's valuable feedback that can help improve Wasp for all users.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CupOfJoe, 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?Hold up may delete this thread
In case you didn't figure it out already, the issue in your original entry was that you declared:
instead of:
Thank you @genyus for the assist 🙂