CodeSandbox link to referenced code sample: https://codesandbox.io/s/boring-bush-l53wc?file=/astro/pages/index.astro (it won't work by itself since Astro is not published yet)
Warning: this is more of a feature abuse/discussion of the current code capability by me instead of a real practical bug report, but it does have some interesting implication when developers use Astro in unintended ways.
Suppose we have an Astro file astro/pages/index.astro
and suppose there is a file astro/pages/social.png
(that we want to reference but not placed in public/
folder (this might not be the intended usage, but some developers might be tempted to do so when migrating):
<html>
<body>
<img src="./social.png" />
</body>
</html>
When running astro build
, ./social.png
won't be resolved. The reason is obvious when reading the code: ./social.png
becomes /social.png
in runtime.load(...)
since it goes through a URL processing phase:
https://github.com/snowpackjs/astro/blob/077fceabcb4a505106ffa832ee252d786bb1e872/src/runtime.ts#L47-L49
And that for Snowpack, path in config.public
is mounted as /
, so the resolution would fail (as there is nothing in the public/
folder). Theoretically this should be considered as a misuse by the developer, but nicer error reporting might be helpful, since currently the error would look like:
[build] NotFoundError: Not Found (/social.png)
Suppose the developer (if s/he is determined enough to not use pubilc/
) tries to read the source code (or just inspect the output _site
folder) and figured out that astroRoot
(default to ./astro
) is in fact mounted on Snowpack as ./_astro
:
https://github.com/snowpackjs/astro/blob/f28cebcf61ae6206383dabc957366b3ab6edb6e1/src/runtime.ts#L249-L252
And therefore in Snowpack the value to key mapping "/_astro/pages/social.png" => "[...]/astro/pages/social.png"
exists, s/he might be tempted to do such:
<html>
<body>
<img src="./_astro/pages/social.png" />
</body>
</html>
Another funny behavior would emerge instead: the runtime.load(...)
on this resource would work, but the following step would write the static file (writeResult(...)
) to ./_astro/pages/social.png
instead of ./_site/_astro/pages/social.png
, thus making the eventually emitted files still broken (as the src
on img
is not touched). This behavior is due to
https://github.com/snowpackjs/astro/blob/f28cebcf61ae6206383dabc957366b3ab6edb6e1/src/build.ts#L196
which, when supplied ./_astro/pages/social.png
, produces ../_astro/pages/social.png
, and thus steps out of _site
and write static files outside.
I don't really have a clear idea about what should be done here, but these 2 cases are potential mistakes that a developer could make, and current error reporting seems do not make things clear when they happen.