Preventing wasp server recompiling when new files created in /public
Hi, i'm developping an app that generates wav files in /public/audio/tmp directory. But each time I generate a file, my wasp server is recompiling. How can I exclude the /public directory, or the .*wav files from making the server recompiling ?
7 Replies
Hi @Glide Orchestra. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
This is a known issue in Wasp where file creation during development triggers unnecessary recompilation. When your server code creates files in the
/public directory, Wasp's file watching mechanism detects these changes and triggers a rebuild.
Based on the knowledge sources, this issue has been reported and acknowledged by the Wasp team. The problem occurs because Wasp uses tools like nodemon in the background to watch for file changes, and it's currently triggering rebuilds even for files that shouldn't cause a rebuild.
There isn't a direct solution provided in the knowledge sources for excluding specific directories from the watch process, but here are some insights from the Wasp team on this issue:
1. The Wasp team has acknowledged this as a bug that needs fixing: Creating files programmatically on the server triggers reloading
2. One of the Wasp team members mentioned that ideally, nodemon could be configured to ignore certain files/directories through methods like CLI flags, package.json settings, or a nodemon.json file, but these options aren't currently exposed through Wasp.
3. There's an open issue to investigate how file watching works in Wasp to improve this behavior: Investigate how our file watching works
Unfortunately, there doesn't appear to be a direct solution available right now to exclude your /public directory or .wav files from triggering recompilation. The Wasp team is aware of this limitation and is working on improvements to their file watching mechanism.
As a temporary workaround, you might consider storing your generated files outside of your Wasp project directory during development, though this would require adjusting your application logic.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Glide Orchestra, 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 for the workaround, i need my generated files to be accessible as they are loaded in an audio player. If I store them outside my Wasp project directory, they won't be accessible for the audio player.
Let me check the knowledge base for you again. One moment! :books:
----------------------
I understand your concern about needing the generated audio files to be accessible to your audio player. This creates a challenge since storing them outside the Wasp project directory would indeed make them inaccessible to your web application.
Based on the knowledge sources, there are a few potential approaches you might consider:
1. Use a proxy server: One of the issues mentioned in the knowledge sources describes using a proxy in front of the main app server to prevent connection issues during server restarts. This approach might help mitigate the impact of the server recompiling, though it doesn't prevent the recompilation itself. As mentioned in this GitHub issue, you could set up a proxy that would maintain connections even when the main server restarts.
2. Serve static assets differently: There's an open issue about serving and uploading dynamic binary assets which acknowledges that Wasp currently lacks proper support for handling dynamic binary assets like images or audio files. The team is aware this is a common use case that should be supported.
3. Consider a
.waspignore file: While not directly mentioned for this specific use case, there is a reference to a .waspignore file in one of the issues that was used to solve a similar problem with file changes. This might potentially be used to ignore certain directories from triggering rebuilds, though the knowledge sources don't provide specific details on how to configure this for your case.
Unfortunately, the knowledge sources don't provide a direct solution for your specific problem of preventing recompilation when adding files to the /public directory while keeping them accessible to the client. This appears to be a limitation in the current version of Wasp that the team is aware of and working to address.
If you need an immediate solution, you might want to reach out directly to the Wasp team on their Discord or GitHub to ask about potential workarounds specific to your use case.
I'm sorry I couldn't provide a more concrete solution based on the available knowledge sources.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Glide Orchestra, 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 maybe could I add a delay before the server restarts ? Is it possible ?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, adding a delay before server restarts is actually a solution that has been discussed by the Wasp team! This approach could help reduce unnecessary recompilations when multiple files change in rapid succession.
According to the knowledge sources, there was a specific GitHub issue addressing this exact problem: Introduce a delay for recompilation upon file change. The Wasp team proposed introducing a delay (e.g., 1 second) between detecting a file change and triggering the recompilation.
The idea is that when a file change is detected, instead of immediately recompiling, Wasp would:
1. Start a timer (e.g., 1 second)
2. If more file changes happen during this period, reset the timer
3. Only trigger recompilation after the timer expires with no further changes
This approach is similar to how other tools like nodemon handle file changes, and it helps prevent multiple rapid recompilations when several files change in quick succession.
However, I don't see information in the knowledge sources about whether this feature was implemented and made available to users as a configurable option. The issue appears to have been closed, which might indicate it was implemented, but there's no explicit documentation provided on how to configure such a delay in your Wasp project.
If you want to explore this further, you might want to check the current Wasp documentation or reach out to the Wasp team on their Discord or GitHub to ask if this feature is available and how to configure it for your specific use case.
Would you like me to help you find more information about other potential solutions to your problem?
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Glide Orchestra, 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?
Hey @Glide Orchestra, that is indeed a bit annoying to develop with. Good thing is that this won't happen in production, this is development only feature.
I think
.waspignore is used to stop copying files to builds, so I don't think it will help here.
I'll call @Filip to help as he is much more up to date with compiler behavior.Hey @Glide Orchestra, there's no official way to do it. But the problem is actually deeper - you shouldn't be saving these files in the
public dir.
The public dir won't be available to your server in production. It's a client-side thing for static resources. You can only currently use it because, during development, your server is on the same computer as the client
So, I recommend saving your files into a different directory (you can create one, just as you would if you weren't using Wasp). Doing so will also solve recompilation issues. For more info, check this answer: https://discord.com/channels/686873244791210014/1278404045941375108/1278660290371649650
We plan to offer first class support for this. I've added this thread to the relevant issue: https://github.com/wasp-lang/wasp/issues/1564#issuecomment-2836379465