astro:config virtual module

[florian-lefebvre]

Body

Summary

Expose common Astro config properties to users and integrations

Background & Motivation

It happens quite often in userland to need the trailingSlash setting, or the base etc. Things that are available at import.meta.env and some that are not. The goal is to unify the way we expose this data.

Many integrations need this data and have to create virtual modules for this anwyays.

Goals

• Have a unified way of exposing Astro config data
• Pick properties, not include everything (eg. integrations)

Example

import { config } from 'astro:config'

config.trailingSlash
config.base
config.i18n.defaultLocale

[jdtjenkins]

This is a great idea, I'd love to see something like this in Astro. That's always the first virtual module I end up adding is one that exposes all this stuff!

[matthewp]

What are some examples of when you would use this? Integration already have these values available to them. Would you use this in a component?

[florian-lefebvre]

I wonder if we should expose this data on the client at all actually. If you need it, maybe it's the right time to have a custom virtual import

[delucis]

Yeah or selectively pass the things you need in another way. In Starlight we pass trailing slash as a data-* attribute in one place where we need it on the client and use it from there.

It would avoid needing to think about stuff like tree-shaking to avoid the entire config ending up in the client bundle unnecessarily (and maybe riskily).

[matthewp]

Are there use-cases outside of integrations? Integration use-cases are valid but if they are the only thing that needs them that could influence the shape of the solution.

[delucis]

Yeah, I suspect integrations or component packages are likely consumers. In a single site, you can often hardcode behaviour, knowing config is fixed. But e.g. a design system’s <Breadcrumbs> component might need to work flexibly between different projects. I guess the component library case is not necessarily an integration.

[ematipico]

A direct use case for users that aren't integrations, it's links

With base, site, trailing slash, i18n, build format, etc. users need to have all this information to make links that always work based on configuration

[ematipico]

This proposal has been accepted and moved to Stage 2 #1099