Referência da Configuração

A referência a seguir cobre todas as opções de configuração suportadas no Astro.

import { defineConfig } from 'astro/config'

export default defineConfig({
  // suas opções de configuração aqui...
})

Opções Top-Level

root

Tipo: 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

{
  root: './diretorio-do-meu-projeto'
}

$ astro build --root ./diretorio-do-meu-projeto

srcDir

Tipo: 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.

{
  srcDir: './www'
}

publicDir

Tipo: 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.

{
  publicDir: './meu-diretorio-public-customizado'
}

outDir

Tipo: 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.

{
  outDir: './meu-diretorio-build-customizado'
}

Veja Também:

build.server

cacheDir

Tipo: 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.

{
  cacheDir: './minha-pasta-de-cache-personalizada'
}

redirects

Tipo: Record.<string, RedirectConfig>
Padrão: {}

Adicionado em: 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]'.

{
  redirects: {
    '/antigo': '/novo',
    '/blog/[...slug]': '/artigos/[...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:

{
  redirects: {
    '/outro': {
      status: 302,
      destination: '/lugar',
    },
  }
}

site

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.

{
  site: 'https://www.meu-site.dev'
}

compressHTML

Tipo: 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.

{
  compressHTML: false
}

base

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.

{
  base: '/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:

{
  base: '/docs/',
  trailingSlash: "never"
}

No exemplo abaixo, os valores de import.meta.env.BASE_URL e config.base serão ambos /docs/ quando processados:

{
  base: '/docs',
  trailingSlash: "always"
}

trailingSlash

Tipo: '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.

{
  // Exemplo: Requer uma barra final durante o desenvolvimento
  trailingSlash: 'always'
}

Veja Também:

build.format

scopedStyleStrategy

Tipo: 'where' | 'class' | 'attribute'
Padrão: 'attribute'

Adicionado em: 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 atributos data-, 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

Tipo: 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.

import netlify from '@astrojs/netlify';
{
  // Exemplo: Faça build para o serverless da Netlify
  adapter: netlify(),
}

Veja Também:

output

output

Tipo: '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.

import { defineConfig } from 'astro/config';

export default defineConfig({
  output: 'static'
})

Veja Também:

adapter

Opções da Build

build.format

Tipo: ('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.

{
  build: {
    // Exemplo: Gera `pagina.html` ao invés de `pagina/index.html` durante a build.
    format: 'file'
  }
}

Efeito no Astro.url

Definir build.format controla o que Astro.url é durante a build. Quando ele for:

directory - O Astro.url.pathname irá incluir uma barra final para imitar o comportamento da pasta; ou seja, /foo/.
file - O Astro.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 - Defina trailingSlash: 'always'
file - Defina trailingSlash: 'never'

build.client

Tipo: 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.

{
  output: 'server', // ou 'hybrid'
  build: {
    client: './client'
  }
}

build.server

Tipo: 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: {
    server: './server'
  }
}

build.assets

Tipo: string
Padrão: '_astro'

Adicionado em: 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.

{
  build: {
    assets: '_customizado'
  }
}

Veja Também:

outDir

build.assetsPrefix

Tipo: string
Padrão: undefined

Adicionado em: 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: {
    assetsPrefix: 'https://cdn.exemplo.com'
  }
}

build.serverEntry

Tipo: 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: {
    serverEntry: 'main.mjs'
  }
}

build.redirects

Tipo: boolean
Padrão: true

Adicionado em: 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: {
    redirects: false
  }
}

build.inlineStylesheets

Tipo: 'always' | 'auto' | 'never'
Padrão: auto

Adicionado em: 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 que ViteConfig.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

{
  build: {
    inlineStylesheets: `never`,
  },
}

Opções de pré-carregamento

Tipo: 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.

<a href="/sobre" data-astro-prefetch>Sobre</a>

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

Tipo: 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.

prefetch: {
  prefetchAll: true
}

Quando definido como true, você pode desabilitar o pré-carregamento individualmente definindo data-astro-prefetch="false" em links individuais.

<a href="/sobre" data-astro-prefetch="false">Sobre</a>

prefetch.defaultStrategy

Tipo: '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.

<a href="/sobre" data-astro-prefetch="viewport">Sobre</a>

Opções do Servidor

Customize o servidor de desenvolvimento do Astro, usado por astro dev e astro preview.

{
  server: { port: 1234, host: true }
}

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.

{
  // Exemplo: Use a sintaxe de função para customizar com base no comando
  server: ({ command }) => ({ port: command === 'dev' ? 4321 : 4000 })
}

server.host

Tipo: string | boolean
Padrão: false

Adicionado em: 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 rede
true - 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

Tipo: 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: { port: 8080 }
}

server.open

Tipo: string | boolean
Padrão: false

Adicionado em: 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: { open: "/sobre" }
}

server.headers

Tipo: OutgoingHttpHeaders
Padrão: {}

Adicionado em: astro@1.7.0

Define headers de resposta HTTP customizados a serem enviados em astro dev e astro preview.

Opções de Imagem

image.endpoint

Tipo: string
Padrão: undefined

Adicionado em: 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: {
    // Exemplo: Use um endpoint de imagem customizado
    endpoint: './src/image-endpoint.ts',
  },
}

image.service

Tipo: Object
Padrão: {entrypoint: 'astro/assets/services/sharp', config?: {}}

Adicionado em: 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: {
    // Exemplo: Habilite o serviço de imagem baseado no Sharp
    service: {
      entrypoint: 'astro/assets/services/sharp',
      config: {
        limitInputPixels: false,
      }
    }
  },
}

image.service.config.limitInputPixels

Tipo: number | boolean
Padrão: true

Adicionado em: 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

Tipo: Array.<string>
Padrão: {domains: []}

Adicionado em: 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: {
    // Exemplo: Permitir otimização de imagem remota de um único domínio
    domains: ['astro.build'],
  },
}

image.remotePatterns

Tipo: Array.<RemotePattern>
Padrão: {remotePatterns: []}

Adicionado em: 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

{
  image: {
    // Exemplo: permitir processamento de todas as imagens do seu bucket do aws s3
    remotePatterns: [{
      protocol: 'https',
      hostname: '**.amazonaws.com',
    }],
  },
}

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

devToolbar.enabled

Tipo: 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

markdown.shikiConfig

Tipo: 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

Tipo: 'shiki' | 'prism' | false
Padrão: shiki

Qual syntax highlighter deve ser utilizado, caso utilize.

shiki - utiliza o highlighter do Shiki
prism - utiliza o highlighter do Prism
false - não aplica syntax highlighting.

{
  markdown: {
    // Exemplo: Mudando para utilizar prism como syntax highlighter em Markdown
    syntaxHighlight: 'prism',
  }
}

markdown.remarkPlugins

Tipo: 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.

import remarkToc from 'remark-toc';
{
  markdown: {
    remarkPlugins: [remarkToc]
  }
}

markdown.rehypePlugins

Tipo: 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.

import rehypeMinifyHtml from 'rehype-minify';
{
  markdown: {
    rehypePlugins: [rehypeMinifyHtml]
  }
}

markdown.gfm

Tipo: boolean
Padrão: true

Adicionado em: astro@2.0.0

Astro usa GitHub-flavored Markdown por padrão. Para desabilitá-lo, defina a flag gfm como false:

{
  markdown: {
    gfm: false,
  }
}

markdown.smartypants

Tipo: boolean
Padrão: true

Adicionado em: astro@2.0.0

Astro usa o formatador SmartyPants por padrão. Para desabilitá-lo, defina a flag smartypants como false:

{
  markdown: {
    smartypants: false,
  }
}

markdown.remarkRehype

Tipo: RemarkRehype

Passe opções para o remark-rehype.

{
  markdown: {
    // Exemplo: Traduza o texto das notas de rodapé para outra língua, aqui estão os valores padrões em Inglês
    remarkRehype: { footnoteLabel: "Footnotes", footnoteBackLabel: "Back to reference 1"},
  },
};

Integrações

Estenda 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.

import react from '@astrojs/react';
import tailwind from '@astrojs/tailwind';
{
  // Exemplo: Adicione suporte a React + Tailwind no Astro
  integrations: [react(), tailwind()]
}

Vite

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

{
  vite: {
    ssr: {
      // Exemplo: Force um pacote quebrado a pular o processamento SSR, se necessário
      external: ['pacote-npm-quebrado'],
    }
  }
}

{
  vite: {
    // Exemplo: Adicione plugins vite customizados diretamente em seu projeto Astro
    plugins: [meuPlugin()],
  }
}

i18n

Tipo: object

Adicionado em: 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

Tipo: string

Adicionado em: 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

Tipo: Locales

Adicionado em: 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

Tipo: Record.<string, string>

Adicionado em: 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

O 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.

export default defineConfig({
  i18n: {
    defaultLocale: "en",
    locales: ["en", "fr", "pt-br", "es"],
    fallback: {
      pt: "es",
      fr: "en"
    }
  }
})

i18n.routing

Tipo: Routing

Adicionado em: 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

Tipo: boolean
Default: false

Adicionado em: 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

Para 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

Astro 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

Tipo: boolean
Padrão: false

Adicionado em: 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: {
    optimizeHoistedScript: true,
  },
}

experimental.contentCollectionCache

Tipo: boolean
Padrão: false

Adicionado em: astro@3.5.0

Habilita um cache persistente para coleções de conteúdo ao fazer o build em modo estático.

{
  experimental: {
    contentCollectionCache: true,
  },
}

Contribua

Comunidade