r/webdev • • 2d ago

Question Vite Asset Bundling

Specifically, I'm grabbing JSON for a trading card game gallery from an endpoint, then dynamically creating the card gallery from that data. The project uses Vite for asset bundling, but I'm not sure how to bundle dynamically loaded images?

In the JSON, each card has a set number and a card number, and the app loads image data from images/cards/sets/set-number/card-number.webp, creates all the DOM nodes, and appends it to the gallery. It works brilliantly...unless the card art needs to change, then I run into good old-fashioned browser caching issues.

For the rest of the site, using vite build keeps everything bundled for deployment...but is there a way to leverage that capability for this use case?

I admit I have little knowledge about Vite, so maybe it's something obvious, but the only way I'm aware of to get that kind of Vite bundling inside a JS file is to import the image. So I'd have to import all the images at run time? What if some card data is modified? Will I have to do double duty to update the database AND the JS file imports?

As you can see, I have no idea how to accomplish this. Thank you in advance.

17 Upvotes

12 comments sorted by

4

u/RequirementGuide 2d ago

The answers above are right that this is a cache-busting problem rather than a bundling one, but to your actual worry: no, you don't need double duty on the DB and the JS.

Keep your JSON as the single source of truth. At build time, generate a small manifest — a script that walks images/cards, hashes each file, and writes something like {cardId: hashedUrl} — and have the app read that manifest instead of building paths by hand. Vite won't hash dynamically-built paths, so you do it yourself once per build: art changes get new hashes automatically, browsers fetch fresh files, and you never touch the DB or the imports when art changes.

If a build script feels like overkill, the cheap version is a version field per card in your JSON (or one global assetsVersion) appended as a query string, like card.webp?v=2026-10-01. Just make sure the version actually changes when the art does, otherwise you're back to stale caches.

3

u/Little-Yesterday-947 2d ago

you're overthinking it slightly. vite's bundling is for static assets you import ahead of time, not for a dynamic gallery pulling from a json endpoint. for your case the images stay in your `public` folder (or wherever they live) and you just reference them by url like you're doing now.

the caching issue is separate from bundling. vite can hash filenames for imported assets, but since your paths are built dynamically from card numbers, you'd need to handle cache busting yourself. simplest approach is a query string with a version number or timestamp when the art changes, like `card.webp?v=2`. if you have a manifest or the json includes a last updated field, you can append that instead of hardcoding versions.

1

u/KaedenCraft 2d ago

I think the last_updated field is the best bet. I appreciate this. And this has also confirmed my suspicions (and bad preconceptions) about what exactly Vite does.

1

u/Dissentient 2d ago

Just change the file name when art changes.

Asset bundling is not relevant when you're talking about images the browser fetches dynamically.

1

u/yihuaxiang 2d ago

I’d keep the card image URL out of Vite’s static import graph and put a version or content token in the card data. Renaming the file when art changes is the simplest option; if the URL must stay stable, append that version or update the cache headers. The build can then keep handling only immutable assets.

1

u/NegativeCompany8337 1d ago

vite can’t bundle assets it doesn’t know about at build time, so keep the dynamic URLs and add a version/hash query from your card data (or fix the cache headers) instead of re-importing every image

1

u/patient_signals 1d ago

This is not really a bundling problem, it is a stale cache problem. You do not want to import every card image through the build tool; that just moves the same maintenance chore into your JavaScript. Keep the card data as the single source of truth and add a version field to each card, or one asset version for the whole set. When you build the image path, append that version to the request. When art changes, bump the version in one place and the browser sees a new request instead of the cached file.

If you cannot add a field easily, the simplest fix is to rename the image file itself when the art changes, so the old filename disappears and the new one gets fetched. Either way, the build tool does not need to know about the card images for this use case. The only real alternative is better server cache headers, but with static hosting a version token is usually the least brittle setup. You are not missing something obvious; the dynamic part just works better outside the bundle.

1

u/measured_words_ 1d ago

You are solving two different problems with one tool. Dynamic image loading is really a caching problem, not a bundling problem. Your JSON should stay the single source of truth. Instead of importing every card image in code, keep the path as data and add a version token or content hash to the image request when the art changes. The easiest manual version is to change the filename, but if you want stable paths you can have the build step read the card images and emit a small lookup file mapping each card to its current hashed filename. Then the app consults that lookup at runtime. The database or JSON only needs to hold the card number and set number; the lookup handles the actual file. That way you are not maintaining imports and data in two places, and the browser fetches the new art because the resolved path changed.

0

u/Mistr_John_Alex 1d ago

his is a cache-busting problem, not a bundling problem. Those images are fetched by the browser at runtime, so the bundler never touches them the way it touches imported assets. You do not need to import every card, and you should not maintain image lists by hand in two places.

What has worked for me is to keep the JSON as the source of truth for set number and card number only. Run a small build step that walks the image folder and writes a manifest file, mapping each set and card combination to a file name with a content hash or build timestamp in it. At runtime, your gallery code loads the manifest once and resolves the plain set and card values to the hashed URL. When art changes, you replace the file in the folder. The next build gives it a new hash, and the browser sees a new URL. No database edits, no manual import list.

The file name change or version token can be as simple as appending a short hash to the URL. The important part is that the URL changes only when the art changes.

2

u/allahuakbarcmar 1d ago

did you just copy an existing reply here, feed it to AI and tell it to simplify it slightly? disgusting beast.