#Correct pattern for creating links that honor `base` setting from config file?

19 messages Β· Page 1 of 1 (latest)

solemn oxide
#

What is the correct Astro way to create HTML a links that honor my config file's base: "/docs" setting? e.g. so href="/blah" becomes href="/docs/blah" after an astro build? πŸ€”

Used the Astro Starter Kit for Blogs: https://github.com/withastro/astro/tree/latest/examples/blog?on=github

npm create astro@latest -- --template blog

Some things honor the base setting (e.g. social URLs, CSS stylesheet href values) but others don't (e.g. favicon, social images, HTML anchor link href values). 😬

GitHub

Build faster websites with Astro's next-gen island architecture 🏝✨ - astro/examples/blog at latest · withastro/astro

native night
#

This is definitely unintuitive behavior that we're hoping to clean up in a v2, but the gist of what gets transformed vs what doesn't is: markup that references bundled assets generated by Astro will include the base, but we won't automatically transform any markup you write yourself. It's on you to use the correct base for favicon, assets in public/, <a href>, etc

solemn oxide
#

Seeing as how the Astro global has a site property but not a base property, what is the correct way to get my base value into .astro component files? Is importing ../astro.config.mjs a legitimate option for a site that is going to be statically generated to host on GitHub Pages? πŸ€”

P.S. Adding Astro.base would be nice 😊 πŸ™

#

Alternatively, I'm considering setting site to include the base path value and NOT setting base but I have a feeling that is going to just screw up different things πŸ˜…

solemn oxide
#

Found a workable but not especially friendly approach.

---
const baseUrl = import.meta.env.BASE_URL.replace(/\/$/, '');
---

<a href={baseUrl + "/about"}>Home</a>

And then astro build --base "/docs" AS WELL AS specifying it for the local preview as well: astro preview --base "/docs"

native night
#

cc @sour vector and @lapis solstice who have been working on this feature/docs

lapis solstice
solemn oxide
#

That definitely doesn't work right since Astro.site doesn't include the base path configuration. πŸ˜…

It appears to maybe build the right HTML if I specifically include the base path in my site configuration instead of in the base configuration, e.g. npx astro build --site "http://localhost:3000/docs"

But it definitely doesn't preview correctly:

npx astro preview --site "http://localhost:3000/docs"
The site configuration value includes a pathname of /docs/ but there is no base configuration.
...
Local    http://localhost:3000/

but then the links include /docs, so they all 404. 😒

I also tried instead previewing with base:

npx astro preview --base "/docs"
...
Local    http://localhost:3000/docs/

Then the links work correctly, but all of the built assets like CSS fail to load. πŸ˜•

For completeness, I also tried specifying both the --site (with base) and --base in the preview but that produced the same behavior as only specifying the base I guess?

npx astro preview --site "http://localhost:3000/docs" --base "/docs"
...
Local    http://localhost:3000/docs/

Again, links work but built assets like CSS fail.

lapis solstice
#

You need to include the base config everywhere, why not just put it in your astro.config file?

#

The site config is not used for astro resolve any paths. It's just used to populate Astro.site

#

So include the base which tells astro to include that base when building link tags, etc. Include site so that you can resolve your own <a> tags, etc using the method above.

solemn oxide
#

<a href={new URL('./about', Astro.site).pathname}>Home</a> does not honor my base path setting

#

You need to include the base config everywhere, why not just put it in your astro.config file?

I could but the reality is that I'd rather not use a base path locally at all. I'm just trying to verify that the Astro behavior will hold up when deploying to a GitHub Pages project site (e.g. https://{user}.github.io/{repo}/) via an Actions workflow (e.g. https://github.com/actions/starter-workflows/blob/main/pages/astro.yml)... and it currently is not doing so since the link URLs aren't including the base path 😬

lapis solstice
#

The <link> should include it if you are providing that flag. If not let me know

silk dirge
#

@solemn oxide
I'm using import.meta.env.BASE_URL which is coming from Astro config base so not clear to me why you still had to pass it as argument unless you did not declare it in Astro config but only as env var. It just serves on the base with pnpm astro preview and so on.
Then I pass it to components and scripts
https://vitejs.dev/guide/env-and-mode.html#env-variables

const baseUrl = import.meta.env.BASE_URL.slice(0, -1)
---
...
<link rel="icon" type="image/svg+xml" href={`${baseUrl}/favicon.svg`} />
...
<script define:vars={{url,uid,isSvg,baseUrl}} type="module">
  await import(`${baseUrl}/panzoom.js`)
...
solemn oxide
#

@lapis solstice Yes, <link ...> elements (like stylesheet URLs) do include the base. However, I also want that base included in my normal hyperlinks (<a href="...">) as well. πŸ˜•

@silk dirge yup, looks like we're on the same base as var as using import.meta.env.BASE_URL. My choosing to pass in --base on commands is a personal thing, mostly I'm trying to nail down that pattern for hosting on GitHub Pages with a repository name in the path, whereas it's not really desirable locally.

silk dirge
#

Right, locally it's annoying during dev, I'm considering using different env var for prod and dev, and use that env var in astro config with dotenv.

lapis solstice
#

I would create a utility function and stick it in another file, makes it a lot each to do fromBase('/favicon.svg')

solemn oxide
#

@lapis solstice Yeah, that seems reasonable for now. πŸ‘ Beyond that, I do still feel like that would be a nice built-in feature to consider for the next major version πŸ€·β€β™‚οΈ