Referência da Configuração
A referência a seguir cobre todas as opções de configuração suportadas no Astro.
Opções Top-Level
Seção intitulada Opções Top-LevelTipo: string
Interface de Linha de Comando: --root
Padrão: "."
(diretório de trabalho atual)
Você deve apenas providenciar esta opção se você executar os comandos da interface de linha de comando astro
em um diretório diferente do que o diretório raiz do projeto. Geralmente, esta opção é providenciada pela interface de linha de comando ao invés do arquivo de configuração Astro, já que Astro precisa saber a raiz do seu projeto antes de poder localizar seu arquivo de configuração.
Se você providenciar um caminho relativo (ex: --root: './meu-projeto'
) Astro irá resolvê-lo com base no seu diretório de trabalho atual.
Exemplos
Seção intitulada ExemplossrcDir
Seção intitulada srcDirTipo: string
Padrão: "./src"
Define o diretório em que Astro irá ler o seu site.
O valor pode ser tanto um caminho absoluto do sistema ou um caminho relativo a raiz do projeto.
publicDir
Seção intitulada publicDirTipo: string
Padrão: "./public"
Define o diretório de seus assets estáticos. Arquivos nesse diretório são servidos em /
durante o desenvolvimento e são copiados para o diretório de saída durante o processo de build. Esses arquivos serão sempre servidos ou copiados da forma que são, sem transformações ou etapa de bundle.
O valor pode ser tanto um caminho absoluto do sistema ou um caminho relativo a raiz do projeto.
outDir
Seção intitulada outDirTipo: string
Padrão: "./dist"
Define o diretório em que astro build
escreve a sua build final.
O valor pode ser tanto um caminho absoluto do sistema ou um caminho relativo a raiz do projeto.
Veja Também:
- build.server
cacheDir
Seção intitulada cacheDirTipo: string
Padrão: "./node_modules/.astro"
Define a pasta para deixar em cache artefatos da build. Arquivos nessa pasta vão ser usados em subsequentes builds para acelerar o tempo de build.
O valor pode ser tanto um caminho absoluto no sistema de arquivos ou um caminho relativo a raiz do projeto.
redirects
Seção intitulada redirectsTipo: Record.<string, RedirectConfig>
Padrão: {}
astro@2.9.0
Especifica um mapeamento de redirecionamentos onde a chave é a rota a corresponder e o valor é o caminho pra onde será redirecionado.
Você pode redirecionar tanto rotas estáticas como dinâmicas, mas somente o mesmo tipo de rota.
Por exemplo, você não pode ter um redirecionamento '/artigo': '/blog/[...slug]'
.
Para sites estaticamente gerados sem nenhum adaptador instalado, isso vai produzir um redirecionamento no cliente usando uma tag <meta http-equiv="refresh">
e não suporta códigos de status.
Quando estiver usando SSR ou um adaptador estático no modo output: static
,
códigos de status não são suportados.
O Astro irá servir requisições GET redirecionadas com um status de 301
e usar um status de 308
para qualquer outro método de requisição.
Você pode customizar o código de status de redirecionamento usando um objeto na configuração de redirecionamento:
Tipo: string
Sua URL final no deploy. Astro utiliza esta URL completa para gerar seu sitemap e URLs canônicas na sua build final. É fortemente recomendado que você defina esta configuração para usufruir ao máximo o que o Astro pode oferecer.
compressHTML
Seção intitulada compressHTMLTipo: boolean
Padrão: true
Esta é uma opção para minificar seu HTML final e reduzir o tamanho dos seus arquivos HTML. Por padrão, o Astro remove todos os espaços em branco do seu HTML, incluindo quebras de linha, de componentes .astro
. Isso ocorre tanto em modo de desenvolvimento e na build final.
Para desabilitar a compressão de HTML, defina a flag compressHTML
como false
.
Tipo: string
O caminho base no qual será feito o deploy. Astro irá utilizar esse caminho como a raiz para suas páginas e assets tanto em desenvolvimento quanto na build para produção.
No exemplo abaixo, astro dev
irá iniciar seu servidor em /docs
.
Au utilizar esta opção, todas as importações de assets e URLs devem adicionar a base como prefixo. Você pode acessar esse valor com import.meta.env.BASE_URL
.
O valor de import.meta.env.BASE_URL
respeita sua configuração de trailingSlash
e irá incluir uma barra final se você explicitamente incluiu uma ou se trailingSlash: "always"
foi definido. Se trailingSlash: "never"
está definido, BASE_URL
não irá incluir uma barra final, mesmo se base
inclui uma.
Uma barra final sempre é incluída se trailingSlash: "always"
estiver definido. Se trailingSlash: "never"
estiver definido, BASE_URL
não incluirá uma barra final, mesmo que base
inclua uma.
Adicionalmente, Astro irá manipular internamente o valor configurado para config.base
antes de torná-lo disponível para integrações. O valor de config.base
lido por integrações também será determinado por sua configuração de trailingSlash
da mesma forma.
No exemplo abaixo, os valores de import.meta.env.BASE_URL
e config.base
serão ambos /docs
quando processados:
No exemplo abaixo, os valores de import.meta.env.BASE_URL
e config.base
serão ambos /docs/
quando processados:
trailingSlash
Seção intitulada trailingSlashTipo: 'always' | 'never' | 'ignore'
Padrão: 'ignore'
Define o comportamento de correspondência de rotas do servidor de desenvolvimento. Escolha entre as seguintes opções:
'always'
- Apenas corresponde URLs que incluem uma barra final (ex: “/foo/“)'never'
- Nunca corresponde URLs que incluem uma barra final (ex: “/foo”)'ignore'
- Corresponde URLs independente da presença de uma ”/” final
Use esta opção de configuração se o seu host de produção lida de forma estrita em como barras finais funcionam ou não.
Você também pode definir isto se você preferir ser mais estrito consigo mesmo, para que então URLs com ou sem barras finais não funcionem durante o desenvolvimento.
Veja Também:
- build.format
scopedStyleStrategy
Seção intitulada scopedStyleStrategyTipo: 'where' | 'class'
| 'attribute'
Padrão: 'attribute'
astro@2.4
Especifica a estratégia usada para definir o escopo de estilos dentro de componentes do Astro. Escolha entre:
'where'
- Usa seletores:where
, não causando aumento de especificidade.'class'
- Usa seletores baseados em classe, causando um aumento de +1 de especificidade.'attribute'
- Usa atributosdata-
, causando um aumento de +1 de especificidade.
Usar 'class'
é útil quando você quer garantir que os seletores de elementos em componentes Astro sobrescrevam os padrões de estilo globais (e.x. de uma folha de estilo global).
Usar 'where'
dá a você mais controle sobre a especificidade, mas requer que você use seletores de especificidade mais alta, camadas e outras ferramentas para controlar quais seletores são aplicados.
Usar 'attribute'
é útil quando você está manipulando o atributo class
de elementos e precisa evitar conflitos entre sua própria lógica de estilização e a aplicação de estilos do Astro.
adapter
Seção intitulada adapterTipo: AstroIntegration
Faça deploy para seu servidor de hospedagem, serverless ou edge favorito com adaptadores de build. Importe um dos nossos adaptadores oficiais para Netlify, Vercel e mais para começar a usar SSR no Astro.
Veja nosso guia sobre Renderização no lado do Servidor (EN) para mais sobre SSR e nossos guias de deploy para uma lista completa de hospedagem.
Veja Também:
- output
output
Seção intitulada outputTipo: 'static' | 'server' | 'hybrid
Padrão: 'static'
Especifica o alvo de saída para builds.
- ‘static’ - Fazendo build de um site estático para fazer deploy em qualquer hospedagem estática.
- ‘server’ - Fazendo build de um app para fazer deploy em uma hospedagem que suporta SSR (renderização no lado do servidor).
- ‘hybrid’ - Fazendo build de um site estático com algumas páginas renderizadas no lado do servidor.
Veja Também:
- adapter
Opções da Build
Seção intitulada Opções da Buildbuild.format
Seção intitulada build.formatTipo: ('file' | 'directory')
Padrão: 'directory'
Controla o formato final do arquivo de cada página. Esse valor pode ser configurado por um adaptador para você.
- Se for ‘file’, Astro irá gerar um arquivo HTML (ex: “/foo.html”) para cada página.
- Se for ‘directory’, Astro irá gerar um diretório com um arquivo
index.html
aninhado (ex: “/foo/index.html”) para cada página.
Efeito no Astro.url
Seção intitulada Efeito no Astro.urlDefinir build.format
controla o que Astro.url
é durante a build. Quando ele for:
directory
- OAstro.url.pathname
irá incluir uma barra final para imitar o comportamento da pasta; ou seja,/foo/
.file
- OAstro.url.pathname
irá incluir.html
; ou seja,/foo.html
.
Isso significa que quando você criar URLs relativas usando new URL('./relativo', Astro.url)
, você terá um comportamento consistente entre dev e build.
Para evitar inconsistências com o comportamento da barra final durante desenvolvimento, você pode restringir a opção trailingSlash
para 'always'
ou 'never'
dependendo do seu formato de build:
directory
- DefinatrailingSlash: 'always'
file
- DefinatrailingSlash: 'never'
build.client
Seção intitulada build.clientTipo: string
Padrão: './dist/client'
Controla o diretório de saída do seu CSS e JavaScript do lado do cliente apenas quando output: 'server'
ou output: 'hybrid'
.
outDir
controla onde o código é construído.
Esse valor é relativo ao outDir
.
build.server
Seção intitulada build.serverTipo: string
Padrão: './dist/server'
Controla o diretório de saída de JavaScript do servidor ao fazer build para SSR.
Esse valor é relativo ao outDir
.
build.assets
Seção intitulada build.assetsTipo: string
Padrão: '_astro'
astro@2.0.0
Especifica o diretório na saída da build onde assets gerados pelo Astro (JS e CSS pós-bundle por exemplo) deve ficar.
Veja Também:
- outDir
build.assetsPrefix
Seção intitulada build.assetsPrefixTipo: string
Padrão: undefined
astro@2.2.0
Especifica o prefixo para links de assets gerados pelo Astro. Isto pode ser utilizado se assets são servidos de um domínio diferente do site atual.
Por exemplo, se ele é definido como https://cdn.exemplo.com
, assets serão buscados de https://cdn.exemplo.com/_astro/...
(independente da opção base
).
Você precisaria fazer upload desses arquivos em ./dist/_astro/
para https://cdn.exemplo.com/_astro/
para providenciar os assets.
O processo varia dependendo em como o domínio de terceiros é hospedado.
Para renomear o caminho _astro
, especifique um novo diretório em build.assets
.
build.serverEntry
Seção intitulada build.serverEntryTipo: string
Padrão: 'entry.mjs'
Especifica o nome de arquivo do entrypoint do servidor ao fazer build para SSR. Esse entrypoint geralmente depende em qual provedor você está fazendo o deploy e será definido pelo seu adaptador por você.
Note que é recomendado que este arquivo termine com .mjs
para que o runtime
detecta que o arquivo é um módulo JavaScript.
build.redirects
Seção intitulada build.redirectsTipo: boolean
Padrão: true
astro@2.6.0
Especifica se os redirecionamentos são enviados como HTML durante a build.
Essa opção só se aplica para o modo output: 'static'
; em SSR os redirecionamentos
são tratados da mesma forma que todas as respostas.
Essa opção é principalmente para ser usada por adaptadores que possuem arquivos de configuração especiais para redirecionamentos e não precisam/querem redirecionamentos baseados em HTML.
build.inlineStylesheets
Seção intitulada build.inlineStylesheetsTipo: 'always' | 'auto' | 'never'
Padrão: auto
astro@2.6.0
Controla se os estilos do projeto são enviados para o navegador em um arquivo CSS separado ou em linha em tags <style>
. Escolha entre as seguintes opções:
'always'
- estilos do projeto são embutidos em tags<style>
'auto'
- apenas folhas de estilo menores queViteConfig.build.assetsInlineLimit
(padrão: 4kb) são embutidas. Caso contrário, estilos do projeto são enviados em folhas de estilo externas.'never'
- estilos do projeto são enviados em folhas de estilo externas
Opções de pré-carregamento
Seção intitulada Opções de pré-carregamentoTipo: boolean | object
Habilita o pré-carregamento de links no seu site para oferecer transições de páginas mais rápidas.
(Habilitado por padrão em páginas que usam o roteador <ViewTransitions />
. Defina prefetch: false
para optar por não ter esse comportamento.)
Essa configuração adiciona um script de pré-carregamento automaticamente em todas as páginas no projeto
lhe dando acesso ao atributo data-astro-prefetch
.
Adicione esse atributo em qualquer link <a />
em sua página para habilitar o pré-carregamento para aquela página.
Customize mais o comportamento padrão de pré-carregamento utilizando as opções prefetch.defaultStrategy
e prefetch.prefetchAll
.
Veja o guia de Pré-carregamento para mais informações.
prefetch.prefetchAll
Seção intitulada prefetch.prefetchAllTipo: boolean
Habilita o pré-carregamento para todos os links, incluindo aqueles sem o atributo data-astro-prefetch
.
Esse valor padrão é true
quando é utilizado o roteador <ViewTransitions />
. Caso contrário, o valor padrão é false
.
Quando definido como true
, você pode desabilitar o pré-carregamento individualmente definindo data-astro-prefetch="false"
em links individuais.
prefetch.defaultStrategy
Seção intitulada prefetch.defaultStrategyTipo: 'tap' | 'hover' | 'viewport' | 'load'
Default: 'hover'
A estratégia de pré-carregamento padrão a ser usada quando o atributo data-astro-prefetch
está definido em um link sem nenhum valor.
'tap'
: Pré-carregar imediatamente antes de você clicar em um link.'hover'
: Pré-carregar ao passar o ponteiro por cima ou focar no link. (padrão)'viewport'
: Pré-carregar conforme os links entram na janela de exibição.'load'
: Pré-carregar todos os links quando a página for carregada.
Você pode sobrescrever esse valor padrão e selecionar uma estratégia diferente para cada link individual definindo um valor no atributo.
Opções do Servidor
Seção intitulada Opções do ServidorCustomize o servidor de desenvolvimento do Astro, usado por astro dev
e astro preview
.
Para definir uma configuração diferente baseada no comando run (“dev”, “preview”) uma função também pode ser passada para esta opção de configuração.
server.host
Seção intitulada server.hostTipo: string | boolean
Padrão: false
astro@0.24.0
Define em quais endereços de IP da rede o servidor deve ser escutado em (ou seja, IPs que não sejam localhost).
false
- não o expõe em um endereço de IP da redetrue
- escutado em todos os endereços, incluindo endereços LAN e públicos[endereço-customizado]
- o expõe ao endereço de IP da rede em[endereço-customizado]
(ex:192.168.0.1
)
server.port
Seção intitulada server.portTipo: number
Padrão: 4321
Define em qual porta o servidor deve ser escutado.
Se a porta indicada já estiver em uso, Astro irá automaticamente tentar a próxima porta disponível.
server.open
Seção intitulada server.openTipo: string | boolean
Padrão: false
astro@4.1.0
Controla se o servidor de desenvolvimento deve abrir em seu navegador ao iniciar.
Passe uma URL completa (e.g. “http://example.com”) ou um nome de caminho (e.g. “/sobre”) para especificar qual URL será aberta.
server.headers
Seção intitulada server.headersTipo: OutgoingHttpHeaders
Padrão: {}
astro@1.7.0
Define headers de resposta HTTP customizados a serem enviados em astro dev
e astro preview
.
Opções de Imagem
Seção intitulada Opções de Imagemimage.endpoint
Seção intitulada image.endpointTipo: string
Padrão: undefined
astro@3.1.0
Define o endpoint a ser utilizado para otimização de imagem em desenvolvimento e SSR. Defina como undefined
para utilizar o endpoint padrão.
Esse endpoint sempre será injetado em /_image
.
image.service
Seção intitulada image.serviceTipo: Object
Padrão: {entrypoint: 'astro/assets/services/sharp', config?: {}}
astro@2.1.0
Defina que serviço de imagem será usado para o suporte de assets do Astro.
O valor deve ser um objeto com um entrypoint para o serviço de imagem a ser usado e opcionalmente, um objeto de configuração para passar ao serviço.
O entrypoint do serviço pode ser tanto um dos serviços inclusos ou um pacote de terceiros.
image.service.config.limitInputPixels
Seção intitulada image.service.config.limitInputPixelsTipo: number | boolean
Padrão: true
astro@4.1.0
Define se o tamanho das imagens que serviço de imagem Sharp vai processar deve ser limitado.
Defina como false
para ignorar o limite de tamanho de imagem padrão para o serviço de imagem Sharp e processar imagens maiores.
image.domains
Seção intitulada image.domainsTipo: Array.<string>
Padrão: {domains: []}
astro@2.10.10
Define uma lista de domínios de fonte de imagem permitidos para otimização de imagem local. Nenhuma outra imagem remota vai ser otimizada pelo Astro.
Essa opção requer uma matriz de nomes de domínio individuais como strings. Coringas não são permitidos. Ao invés disso, use image.remotePatterns
para definir uma lista de padrões de URL de origens permitidos.
image.remotePatterns
Seção intitulada image.remotePatternsTipo: Array.<RemotePattern>
Padrão: {remotePatterns: []}
astro@2.10.10
Define uma lista de padrões de URL de origem de imagem permitidos para otimização de imagem local.
remotePatterns
pode ser configurado com quatro propriedades:
- protocol
- hostname
- port
- pathname
Você pode usar coringas para definir os valores permitidos de hostname
e pathname
como descrito abaixo. Caso contrário, apenas os valores exatos fornecidos serão configurados:
hostname
:
- Comece com ’**.’ para permitir todos os subdomínios (‘termina com’).
- Comece com ’*.’ para permitir apenas um nível de subdomínio.
pathname
:
- Termine com ’/**’ para permitir todas as sub-rotas (‘começa com’).
- Termine com ’/*’ para permitir apenas um nível de sub-rota.
Opções da Barra de ferramentas de Desenvolvimento
Seção intitulada Opções da Barra de ferramentas de DesenvolvimentodevToolbar.enabled
Seção intitulada devToolbar.enabledTipo: boolean
Padrão: true
Habilita a barra de ferramentas de desenvolvimento do Astro. Essa barra de ferramentas lhe permite inspecionar as ilhas de sua página, ver auditorias úteis sobre performance e acessibilidade, e mais.
Essa opção tem como escopo o projeto inteiro, para desabilitar a barra de ferramentas apenas para você mesmo, rode npm run astro preferences disable devToolbar
. Para desabilitar a barra de ferramentas para todos os seus projetos Astro, rode npm run astro preferences disable devToolbar --global
.
Opções de Markdown
Seção intitulada Opções de Markdownmarkdown.shikiConfig
Seção intitulada markdown.shikiConfigTipo: Partial<ShikiConfig>
Opções da configuração do Shiki. Veja a documentação da configuração de Markdown para entender como configurá-lo.
markdown.syntaxHighlight
Seção intitulada markdown.syntaxHighlightTipo: 'shiki' | 'prism' | false
Padrão: shiki
Qual syntax highlighter deve ser utilizado, caso utilize.
shiki
- utiliza o highlighter do Shikiprism
- utiliza o highlighter do Prismfalse
- não aplica syntax highlighting.
markdown.remarkPlugins
Seção intitulada markdown.remarkPluginsTipo: RemarkPlugins
Passe plugins remark para customizar como seu Markdown é construído. Você pode importar e aplicar a função do plugin (recomendado), ou passar o nome do plugin como uma string.
markdown.rehypePlugins
Seção intitulada markdown.rehypePluginsTipo: RehypePlugins
Passe plugins rehype para customizar como o HTML resultante do seu Markdown é processado. Você pode importar e aplicar a função do plugin (recomendado), ou passar o nome do plugin como uma string.
markdown.gfm
Seção intitulada markdown.gfmTipo: boolean
Padrão: true
astro@2.0.0
Astro usa GitHub-flavored Markdown por padrão. Para desabilitá-lo, defina a flag gfm
como false
:
markdown.smartypants
Seção intitulada markdown.smartypantsTipo: boolean
Padrão: true
astro@2.0.0
Astro usa o formatador SmartyPants por padrão. Para desabilitá-lo, defina a flag smartypants
como false
:
markdown.remarkRehype
Seção intitulada markdown.remarkRehypeTipo: RemarkRehype
Passe opções para o remark-rehype.
Integrações
Seção intitulada IntegraçõesEstenda Astro com integrações customizadas. Integrações são sua via de mão única para adicionar suporte a frameworks (como Solid.js), novas funcionalidades (como sitemaps) e novas bibliotecas (como Partytown).
Leia nosso Guia de Integrações para mais ajuda em como começar a utilizar Integrações Astro.
Passe opções de configuração adicionais ao Vite. Útil quando o Astro não suporta algumas configurações avançadas que você pode precisar.
Veja a documentação completa do objeto de configuração vite
em vite.dev.
Exemplos
Seção intitulada ExemplosTipo: object
astro@3.5.0
Configura o roteamento i18n e lhe permite especificar algumas opções de customização.
Veja nosso guia para mais informações sobre internacionalização no Astro (EN)
i18n.defaultLocale
Seção intitulada i18n.defaultLocaleTipo: string
astro@3.5.0
A língua padrão do seu site/aplicação. Esse é um campo obrigatório.
Nenhum formato ou sintaxe específico de língua é imposto, mas sugerimos utilizar letras minúsculas e hífens conforme necessário (e.g. “es”, “pt-br”) para máxima compatibilidade.
i18n.locales
Seção intitulada i18n.localesTipo: Locales
astro@3.5.0
Uma lista com todas as línguas suportadas pelo website, incluindo a defaultLocale
. Esse é um campo obrigatório.
Idiomas podem ser listados tanto como códigos individuais (e.g. ['en', 'es', 'pt-br']
) ou mapeados para um path
de códigos compartilhados (e.g. { path: "inglês", codes: ["en", "en-US"]}
). Esses códigos serão utilizados para determinar a estrutura de URLs do seu site deployado.
Nenhum formato ou sintaxe específico de língua é imposto, mas as pastas content os arquivos do seu projeto dever coincidir exatamente com os itens na lista de locales
. No caso de múltiplos codes
apontando para um prefixo de URL customizado, armazene seus arquivos de conteúdo em uma pasta com o mesmo nome que o path
configurado.
i18n.fallback
Seção intitulada i18n.fallbackTipo: Record.<string, string>
astro@3.5.0
A estratégia de fallback para quando navegar para uma página que não existe (e.g. uma página traduzida ainda não foi criada).
Use esse objeto para declarar a rota locale
de fallback para cada idioma que suprotar. Se nenhum fallback for especificado, então páginas indisponíveis retornarão 404.
Exemplo
Seção intitulada ExemploO exemplo a seguir configura a estratégia fallback do seu conteúdo para redirecionar páginas indisponíveis em /pt-br/
para suas versões es
, e páginas indisponíveis em /fr/
para suas versões en
. Páginas /es/
indisponíveis retornarão 404.
i18n.routing
Seção intitulada i18n.routingTipo: Routing
astro@3.7.0
Controla a estratégia de roteamento para determinar as URLs do seu site. Defina isso baseado nas configurações de caminho de pasta/URL para seu idioma padrão.
i18n.routing.prefixDefaultLocale
Seção intitulada i18n.routing.prefixDefaultLocaleTipo: boolean
Default: false
astro@3.7.0
Quando false
, somente idiomas não-padrão exibirão um prefixo de idioma.
A defaultLocale
não exibirá um prefixo de idioma e arquivos de conteúdo não existem em uma pasta localizada.
URLs terão o formato example.com/[língua]/conteudo/
para todos os idiomas não-padrão, mas example.com/conteudo/
para a língua padrão.
Quando true
, todas as URLs exibirão um prefixo de idioma.
URLs terão o formato example.com/[língua]/conteudo/
para todas as rotas, incluindo o idioma padrão.
Pastas localizadas são utilizadas para todos os idiomas, incluindo o padrão.
Flags Legado
Seção intitulada Flags LegadoPara ajudar usuários a migrarem entre versões do Astro, nós ocasionalmente introduzimos flags legacy
.
Estas flags te permitem optar por um descontinuado ou antigo comportamento do Astro
na versão mais recente, para que então você possa continuar atualizando e se aproveitando de novas versões do Astro.
Flags Experimentais
Seção intitulada Flags ExperimentaisAstro oferece flags experimentais para dar aos usuários acesso antecipado a novas funcionalidades. Não há garantia que essas flags são estáveis.
experimental.optimizeHoistedScript
Seção intitulada experimental.optimizeHoistedScriptTipo: boolean
Padrão: false
astro@2.10.4
Previne que scripts de componentes não utilizados sejam incluídos em uma página de forma inesperada. A otimização é feita com base na melhor estimativa e pode inversamente deixar de incluir scripts utilizados. Tenha certeza de que checou as páginas da sua build antes de publicar. Habilite a otimização por análise de scripts hoisted adicionando a flag experimental:
experimental.contentCollectionCache
Seção intitulada experimental.contentCollectionCacheTipo: boolean
Padrão: false
astro@3.5.0
Habilita um cache persistente para coleções de conteúdo ao fazer o build em modo estático.
Reference