T
TyphonJS•2y ago
geoidesic

How to include static assets?

I tried adding an /assets folder to the project root, and referring to it like this:
<img src="/assets/logo.webp" />
<img src="/assets/logo.webp" />
But that yields a 404
Request URL: http://localhost:30001/assets/logo.webp
Request Method: GET
Status Code: 404 Not Found
Remote Address: [::1]:30001
Referrer Policy: strict-origin-when-cross-origin
Request URL: http://localhost:30001/assets/logo.webp
Request Method: GET
Status Code: 404 Not Found
Remote Address: [::1]:30001
Referrer Policy: strict-origin-when-cross-origin
What's the correct way?
No description
11 Replies
Unknown User
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
geoidesic
geoidesic•2y ago
Looks interesting... any idea how to make it point to a static assets folder? I had a go but couldn't make it work. I tried:
proxy: {
"^(/systems/surge/assets/*)": "http://localhost:30000",
proxy: {
"^(/systems/surge/assets/*)": "http://localhost:30000",
And various other combinations without luck I also tried all the examples given and none of them work within the context of yarn dev
TyphonJS (Michael)
TyphonJS (Michael)•2y ago
So, I'm kind of detecting from the code above that you are not familiar with how the Foundry server serves data and that this is a lack of understanding of a more fundamental nature. Foundry serves the core files from the root of the server ./resources/app/public. It also serves the user data files from the /Data directory. That makes your image source URL path systems/surge/assets/logo.webp. It is important to not use an absolute URL path starting with / as the Foundry server also supports "route prefixes". This is configured in the user data at ./Config/options.json and the routePrefix option. If you set that to a string like test and restart the server it serves from http://localhost:30000/test/. So it's important to not use absolute URLs. Sometimes in your code where you are handling things directly you'll need to use foundry.utils.getRoute() to construct a final URL w/ the route prefix. Sometimes Foundry does it automatically depending on which core API you are using. I recommend reversing your Vite config changes to the dev server proxy settings and create valid URLs / learn how Foundry is serving the files that it does. The only thing you should need to change is the systems/surge replacement in your config instead of modules/essential-svelte-esm or the similar template repo replacement. I also recommend eventually testing your system with a route prefix. The same goes for any package as it is easy to miss something that breaks when a route prefix is enabled.
geoidesic
geoidesic•2y ago
@mleahy thanks for the insights. I have got it working in the Desktop app using this:
<img class="inline flex2" src="systems/surge/assets/logo.webp" />
<img class="inline flex2" src="systems/surge/assets/logo.webp" />
However, this doesn't work when I'm using the dev server (e.g. yarn dev).
Unknown User
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
geoidesic
geoidesic•2y ago
GitHub
surge/vite.config.mjs at main · geoidesic/surge
Just a test for converting typhonjs-fvtt-demo/template-svelte-esm into a system instead of a module - surge/vite.config.mjs at main · geoidesic/surge
Unknown User
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
geoidesic
geoidesic•2y ago
The /api rule was from the link you shared near the top of this thread... I was just trying to get some proxy working.
Unknown User
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
geoidesic
geoidesic•2y ago
Thanks. I copied the vite.config.js from the Titan project, which is where that problem krept in. It's working now 🔥
TyphonJS (Michael)
TyphonJS (Michael)•2y ago
It's not in the Titan Vite config which is using the default config for those settings from the current demo repos: https://github.com/Solidor777/Titan-VTTRPG/blob/main/vite.config.mjs#L65-L70 The api thing is copy pasta when you looked at the Vite config docs likely. Granted understanding the docs is the next thing to strive for I suppose as the answer was right there, but you did have to adapt it to your use case. I will modify the demo repos to include common static paths like packs / assets, in addition to lang and also attach a clear comment on what is proxied and a link to the Vite documentation for the next TRL release. The Vite dev server in the config provided from the demo repos is primarily for serving the HMR code changes from ./src and doesn't serve static assets hence why you need to set up the proxy rules for the dev server.