embedded assets

[mbostock]

Allows additional paths, backed either by static files or data loaders, to be included in the built output under stable URLs. For example it could be /robots.txt or it could be /product/413021.svg.

[Fil]

I've tested, building works like a charm (even from archives… which was expected but nonetheless nice to see).

Proto-documentation (to go at the bottom of files.md):

<a name="static-assets" href="#static-assets"></a>Static assets listed as
[**dynamicPaths**](./config#dynamic-paths) will be built at the given path instead of
being promoted to content-hashed file attachments.
This allows you to create the handful of (non HTML) ressources that must be served from an
invariable URL, such as an ATOM or RSS feed. (If you reference these assets from a link,
set `rel=external` or use an absolute URL to avoid duplication.)

What remains to do:

• avoid promoting a static asset to a file attachment
  • e.g. <link rel="alternate" href="./feed.xml"> should check if /feed.xml is a dynamicPath before promoting it to _file/feed.12345678.xml); then the last sentence of the documentation could be removed. (not obvious to me how to do this).
• serve static assets in preview

[mbostock]

avoid promoting a static asset to a file attachment

I don’t think we should do this. If you link to it and we detect it, you should get the content-hashed version (even if that means the file exists twice). If you don’t want that, you need to use rel="alternate external" to opt-out (but not sure if that works for RSS detection… hopefully? We could strip the external annotation during build maybe).

Also don’t think we need to serve these during preview.

[Fil]

OK for not serving them, but is this more like "not a priority" or are there arguments against it?

[mbostock]

I guess I’m thinking about these assets as intended for external consumption (for embedding), not for use internally within a Framework application. But you’re right, the preview server could support it, just like it supports CORS so you can test your embedded modules locally…

[mbostock]

I think the documentation should go in /embeds, not /files. That’s the one thing left for this PR IMO.

[mbostock]

I added documentation in #1692, forgetting that I hadn’t merged this yet. 🤦 Any blockers for this PR @Fil?