sveltejs / sveltejs/kit

Feature Request: Always request version.json from same host rather than external assets URL

Open
#9,812 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

p2-nice-to-have
Dominant language
JavaScript
Stars
20.8k
Forks
2.3k
Avg merge
1d 16h
Merged PRs (30d)
156

Description

Describe the problem

Using an external storage bucket or CDN for the build static assets for the Node adapter has some rough edges if you're going to want to be able to easily deploy/rollback builds, or if you want to be able to promote the identical builds/images from a dev environment to a production environment.

Everything in /_app/immutable/ is fine, since it's hashed based on content, and the output of a bunch of different builds can happily live alongside each other in the bucket/CDN/whatever. The issue arises with /_app/version.json, which is always at a fixed path.

Firstly, this makes deploying or rolling back complicated, because you now need to update this file in the storage bucket at the exact same instant you deploy the app. You can't copy this asset into the bucket at build time - it has to be at deploy time - and it needs to be precisely at deploy time in order to not risk causing weird issues for people who already have the app open in their browser at the time.

Secondly, whatever assets and appDir paths you specify get baked into the built app. This means you cannot promote images from development to production, because they'll both be pointing at the same external assets and will get the same version.json for any environment, regardless of what version of the app image is deployed there.

Lastly, trusting the storage bucket to know what version of the app is deployed just seems like an unwise coupling and mixing of concerns. The app itself should be the source of truth for what version of it is currently deployed.

Describe the proposed solution

Requests for the /_app/version.json file (or whatever appDir has been set to) should be made relative to the application itself, rather than to the potentially external assets path.

I'm not entirely sure what this means in practice. I'm assuming that version.json is still going to be accessible somewhere within the application even if an external assets path has been specified. We just need to make sure we request it from whatever that path is.

If it's necessary, we could also move the generated version.json to some other path that doesn't rely on appDir, since that's defined as being relative to the assets path, which could get messy if we want to sometimes ignore the assets part.

Alternatives considered

I'm not sure. In my case, we might also be able to route only the /_app/immutable/ requests at the infrastructure level to the storage bucket. The app would continue to request and serve these as living on the same host. The /_app/version.json file would get served by the app, as required, and the /_app/immutable/ files would get served quickly and efficiently from the storage bucket.

Importance

would make my life easier

Additional Information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how the Node adapter generates and serves version.json, and how appDir and the external assets path are applied to requests. Check whether version.json is available from the application host when assets are external. Done means version.json requests use the deployed application as their source while immutable assets can still use the configured external path.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, node.js
Domain
backend, devops
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.