remove /_file/?

[Fil]

Having a /_file/ directory for the file attachments adds complexity https://github.com/observablehq/cli/blob/83ae9c2d5a0442550803ac7cf43cfac70228a384/src/files.ts#L21
and adds an indirection between the structure of docs/ and the structure of dist/.

If it's not a requirement for us or the platform, I'd suggest we remove this, and serve the files at their "natural" place. We might want instead to detect conflicts between FileAttachement("page.html") and page.md, and error.

[mbostock]

I moved this issue to Early access since it doesn’t block any requirements for Internal access, but does have (a small) user-visible impact. (Though I think this is small enough that we should consider moving to General availability or Future.)

I agree, though, and have been thinking the same. 👍 My original motivation was to prevent a potential collision between a generated index.html from index.md, and a static file named index.html. But I think that was just a theoretical concern and not a practical one.

If we remove _file we should also try to remove _import. Removing _import is a bit trickier because it means we’ll rewrite fetched JavaScript as well as imported JavaScript. But the use case of fetching JavaScript also seems a bit theoretical… so it’s probably fine.

Related, I also think we’ll want a static assets folder #169, and that would provide a way to opt-out of rewriting JavaScript. (Meaning, if you don’t want the JavaScript to be rewritten, you put it in docs/public folder instead of in docs.) And those static assets would get merged into dist so the user would be responsible for avoiding collisions.

[mbostock]

Per recent discussion, I believe we are not planning to do this. From the thread:

We have to rewrite the code for a few reasons:

1. For imports during preview, we have to bake-in the content hash to support hot module replacement. If we don’t, there’s no way to replace a previously-imported module. (Once you import a given URL, it can never change; there’s no control of caching behavior.)
2. For files (assume FileAttachment here Support FileAttachment in local ES modules #15, but we currently do it for fetch), we have to rewrite the code to resolve the file path relative to the current module. This behavior happens automatically for import, but fetch is otherwise resolved relative to the page. So since an imported module can be used on multiple pages in different directories, we have to resolve the path relative to the module using import.meta. (I’d prefer to use import.meta.resolve, but import.meta.url has broader support.)
3. If we don’t rewrite the code, then to validate the behavior of static analysis during preview the preview server would have to verify that each request for a file or imported module is statically referenced somewhere in the project. That reference can exist anywhere in the project, so it would mean parsing every page and every transitively imported module which is practically challenging! (Perhaps we could use the referrer to enforce that it’s referenced by the specific page making the request, but this isn’t reliable and also wouldn’t match the behavior in production.)
4. During build, we want to generate content-hashed names to force cache breaking Use hashed names to ensure cache-breaking on deploy #260 across deploys while also allowing cache-control: immutable for optimal performance.