Collocated assets with author-controlled URL, aka content bundles

[innermatrix]

This discussion is a reboot of the RFC issue 1618.

I am writing it from scratch, because I think I can word it better now.

What I want to accomplish

1. Store a page and its related assets together in the source tree. For example, if a page includes images or other media, I want to keep the page source and the image files in the same folder.
2. Control URLs of those assets

Note that

• I am not asking to keep site assets (such as components stylesheets, global JS, banner images, etc) together with page sources
• I am not asking to control URLs of all assets. For example, if the page contains a hoisted script, I am not interested in controlling the location of that script

What this is about is that

1. I have some assets that I consider public (for example, a downloadable file), and I want to control the URL of public assets (because I consider the URL to be part of the public "API" of my site — I want the URL to be durable if linked externally)
2. Some of those assets pertain to individual pages, and therefore I want to collocate them with their page sources.

Also worth noting is that this is a common feature in other competing products (for example, Hugo package bundles).

Why can't I do this today

When I tried to do this in 0.20.x, I ran into several problems

• When I put an image asset and the page source in the same folder inside src/pages, I got compiler errors
• I could get around the compiler errors by putting the asset in public, but that doesn't meet my requirement [Roadmap] Astro v1.0 #1
• I could also get around the compiler errors by putting the asset in src/elsewhere, but that doesn't meet either of my requirements

I do not believe this situation is changed in 0.21.

What I would like to do about this

I like the current mechanism of importing an asset from a page to indicate to the compiler that the asset should be compiled into the output. I would like to meet my needs by making two changes to this mechanism:

1. Allow an imported asset to reside in src/pages without causing compiler errors and
2. Allow import of an asset to indicate that the asset should be relocated to /path/to/asset/ rather than /_astro/path/to/asset. I see at least two ways of doing this

Option a

Use import assetRef from "asset"; as today, but assume that any asset in src/pages should be relocated to /path rather than /_astro/path. This is probably the easiest, but also most likely to cause the opposite problem for someone who likes the current behavior and would have to move the assets out of src/pages to get it back.

Option b

Extend import assetRef from "asset"; so that it can be used either as assetRef.private (which would give the current behavior of relocating to /_astro/path) or as assetRef.public (which would give the next behavior of relocating to /path).

(Optionally allow use of bare assetRef to behave like assetRef.private to maintain backwards compatibility.)

My understanding from the conversations thus far (in issue thread and in weekly RFC review) is that there is broad consensus among core devs that this is a valuable feature, but I did not previously make a concrete proposal, and as such no concrete discussion took place. I am hoping that this rewrite will change that situation.

If this discussion leads to a broad agreement that this feature is desirable and that the proposed approach is viable (or yields a different viable approach), I will write up and submit an RFC.