Accessing static files
I need my app to access a collection of static JSON Schema files, but it doesn't seem straightforward to do so. The files are currently positioned in the server/utils/schemas directory, but this directory isn't included in .wasp/out/sdk/wasp/dist/ext-src. It is included in .wasp/out/sdk/ext-src, which is where I'm currently having to reference them from, but I suspect this location won't be valid for the deployed application.
As the
__directory
and __file
magic variables aren't available, here's my current, hacky, implementation:
What's the accepted best practise to accomplish this?11 Replies
Hi @genyus. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the knowledge sources provided, it appears that accessing static files in Wasp, particularly on the server-side, is not straightforward and there isn't a well-established best practice for this yet. However, I can provide some insights and potential workarounds based on the available information.
1. Current limitations:
Wasp doesn't currently have a built-in mechanism for handling static assets on the server-side. As mentioned in this GitHub issue comment (https://github.com/wasp-lang/wasp/issues/609), when deploying, files in the
server/
directory that are not TypeScript/JavaScript files are skipped by the TypeScript compiler and don't make it into the final build.
2. Potential workaround:
The same GitHub issue comment suggests a potential solution that the Wasp team is considering: creating a special directory, such as server/assets/
, and ensuring that whatever is put there is copied to the built server code during wasp build
.
3. Current recommendation:
For now, the most reliable way to handle static files like your JSON schemas would be to place them in the src/
directory. As mentioned in this GitHub comment (https://github.com/wasp-lang/wasp/issues/1919), you can put assets at the src/
level if they are not client-specific (meaning you might use them on the server as well).
Here's a suggested approach:
1. Move your JSON schema files to src/schemas/
directory.
2. Update your getSchema
function to reference this new location:
This approach should work both in development and when deployed, as the src/
directory is included in the build.
It's worth noting that this is not an ideal solution, and the Wasp team is aware of the need for better support for static assets. As mentioned in this GitHub issue (https://github.com/wasp-lang/wasp/issues/609), they are considering improvements to handle static resources more effectively in future versions of Wasp.
For now, if you need a more robust solution or if this approach doesn't work for your specific use case, you might want to consider alternative methods of storing and accessing your JSON schemas, such as using a database or an external file storage service.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @genyus, 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 The schema files are already in a sub-directory of the src folder, but the proposed modification doesn't work in the local environment.
process.cwd()
resolves to .wasp/out/server and the src folder in that directory doesn't contain the static files; which are only available in .wasp/out/sdk/wasp/ext-srcLet me check the knowledge base for you again. One moment! :books:
----------------------
I apologize for the confusion in my previous answer. You're right that the situation is more complex than I initially suggested. Let me provide a more accurate explanation based on the information available in the knowledge sources.
The issue you're facing is related to how Wasp handles file structures during development and build processes. As you've correctly pointed out,
process.cwd()
resolves to .wasp/out/server
in the local environment, which doesn't contain the static files you need.
Unfortunately, the knowledge sources don't provide a clear, officially supported solution for this specific scenario. However, we can infer some insights:
1. File structure changes: As mentioned in this GitHub comment (https://github.com/wasp-lang/wasp/issues/811), Wasp has undergone significant changes in its file structure, particularly with the release of Wasp 0.12.0. This might be contributing to the confusion about file locations.
2. Lack of official support: This GitHub issue (https://github.com/wasp-lang/wasp/issues/1564) indicates that there isn't a well-documented way to import JSON files or read static files on the server side in Wasp yet. The team acknowledges this as an area that needs improvement in the documentation.
3. Potential workaround: While not ideal, you might be able to use a relative path from your current file location to reach the .wasp/out/sdk/wasp/ext-src
directory where your files are available. However, this approach is fragile and might break in production or future Wasp versions.
Given these limitations, here are a few suggestions:
1. Raise an issue: Consider opening a new issue on the Wasp GitHub repository (https://github.com/wasp-lang/wasp/issues) to bring attention to this specific use case. The Wasp team seems responsive to user needs and might provide a better solution or prioritize this feature.
2. Alternative storage: As a temporary workaround, you might want to consider storing your JSON schemas in a different format or location that's more easily accessible in both development and production environments. This could include embedding the schemas directly in your code (if they're not too large) or using a database to store and retrieve them.
3. Environment-specific paths: You could try implementing a solution that uses different paths based on the environment (development vs. production). However, this would require careful testing and might not be reliable across all deployment scenarios.
I apologize that I can't provide a more definitive solution. The handling of static files, especially on the server side, appears to be an area where Wasp is still evolving. The team is aware of these limitations, as evidenced by this GitHub issue (https://github.com/wasp-lang/wasp/issues/609), and they're considering improvements for future versions.
For now, I'd recommend reaching out to the Wasp community through their GitHub issues or Discord channel for the most up-to-date advice on handling your specific use case.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @genyus, 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?@Wasp Team Looking at the referenced issue (https://github.com/wasp-lang/wasp/issues/609), it's been marked as closed by https://github.com/wasp-lang/wasp/pull/1229, but that PR appears to only address client-side assets, not server-side ones. I recognise this is still a WIP, but can anyone explain how I should manage assets in a way that will work both in development and production, at present? I'm currently thinking to just hard-code the two respective paths and use whichever one exists?
GitHub
Support for static assets in Wasp project · Issue #609 · wasp-lang/...
Right now, if you have a static asset like an image or similar that you want to use in Wasp app, you can put it in ext/ and import it via import statement in your JS code, and that works. However, ...
GitHub
Adds support for a client public folder by infomiho · Pull Request ...
Fixes #9
If the user created a public folder in the their client folder -> it will get merged with the React app's public folder.
This means that users can expose client files at / m...
We are tracking this here: https://github.com/wasp-lang/wasp/issues/1564
GitHub
Explain in docs how to import JSON files / read static files in Was...
Right now it is a bit tricky because you can't directly import .json with node (at least 18), and people get surprised with it because error message is confusing (claims there is no file). I ex...
One way you could go about it is to store the static schemas in some remote location (e.g. S3 or R2) and download them to a known location if they don't exist e.g.
/data
and then you know the absolute path where they will be available.
Alternatively, you could modify the Wasp server app's Dockerfile to copy extra file you need (that would require you to go full custom with your deployment).
Let me know if any of those work for you 🙂Overview | Wasp
Wasp apps are full-stack apps that consist of:
I definitely won't be going down the second route, but will explore the first. Thank you for the pointers
Wohooo @genyus, you just became a Waspeteer level 2!
Hey, I've tried this in a custom API endpoint with the
./src/static.txt
:
And this works, but it relies on Wasp's internal SDK structure and might change in the future. ext-src
is not really a part of our public API that intended for users to use. So... this will work, but it might break for you in the future, so I still recommend the options I mentioned.Thanks for confirming. I figured this approach was likely unreliable, but it works for now and I've added a task to my backlog to implement your suggested solution at some point
Turns out that this is another question springing from my relative unfamiliarity with Typescript. I was trying to load JSON schemas from .json files, but TIL you can just define them directly in TS, which is way cleaner.
Oh yes! Or in JS, not TS specific.