API de Integrações Astro
Integrações Astro adicionam novas funcionalidades e comportamentos ao seu projeto com apenas algumas linhas de código.
Esta página de referência é para qualquer um que esteja escrevendo sua própria integração. Para aprender como utilizar uma integração em seu projeto, veja o nosso guia, Usando Integrações no lugar.
Exemplos
As integrações Astro oficiais podem ser utilizadas como referência enquanto você constrói suas próprias integrações.
- Renderizadores:
lit
(EN),svelte
(EN),react
(EN),preact
(EN),vue
(EN),solid
(EN) - Bibliotecas:
tailwind
,partytown
(EN) - Funcionalidades:
sitemap
(EN)
Referência Rápida da API
Hooks
astro:config:setup
Próximo hook: astro:config:done
Quando: Durante a inicialização, antes da configuração do Vite ou Astro ser resolvida.
Por que: Para estender a configuração do projeto. Isso inclui atualizar a configuração do Astro, aplicar plugins Vite, adicionar renderizadores de componentes, e injetar scripts na página.
Opção config
Tipo: AstroConfig
Uma cópia de somente leitura da configuração Astro suprida pelo usuário. Isto é resolvido antes de qualquer outra integração ser executada. Se você precisa de uma cópia da configuração depois de todas as integrações completarem seus processos de atualização da configuração, veja o hook astro:config:done
.
Opção command
Tipo: 'dev' / 'build'
dev
- Projeto é executado a partir deastro dev
ouastro preview
build
- Projeto é executado a partir deastro build
Opção isRestart
Tipo: boolean
false
quando o servidor de desenvolvimento inicia, true
quando um recarregamento é provocado. Útil para detectar quando esta função é chamada mais de uma vez.
Opção updateConfig
Tipo: (newConfig: Record<string, any>) => void;
Uma função de callback para atualizar a configuração Astro suprida pelo usuário. Qualquer configuração que você providenciar será mesclada com a configuração do usuário + atualizações da configuração de outras integrações, então você está livre para omitir as chaves!
Por exemplo, digamos que você precisa fornecer um plugin Vite ao projeto do usuário:
Opção addRenderer
Tipo: (renderer:
AstroRenderer
) => void;
Exemplos: lit
, svelte
, react
, preact
, vue
, solid
Uma função de callback para adicionar um renderizador de um framework de componentes (ex. React, Vue, Svelte, etc). Você pode explorar os exemplos e definições de tipagem acima para opções mais avançadas, mas aqui estão as duas principais opções que você precisa estar ciente sobre:
clientEntrypoint
- caminho para um arquivo que é executado no cliente sempre que seu componente é utilizado. Esta é principalmente utilizado para renderizar ou hidratar seu componente com JS.serverEntrypoint
- caminho para um arquivo que é executado durante requisições no lado do servidor ou builds estáticas sempre que seu componente é utilizado. Esta deve renderizar componentes para uma marcação estática, com hooks para hidratação aonde aplicável. o callbackrenderToString
do React é um exemplo clássico.
Opção addWatchFile
Tipo: URL | string
Se sua integração depende em algum arquivo de configuração que o Vite não observa e/ou precisa de um reinício completo do servidor de desenvolvimento para funcionar, o adicione com addWatchFile
. Sempre que o arquivo mudar, o servidor de desenvolvimento do Astro será recarregado (você pode verificar quando um recarregamento acontece com isRestart
).
Exemplo de uso:
Opção addClientDirective
Adicionado em:
astro@2.6.0
Tipo: (directive:
ClientDirectiveConfig
) => void;
Adiciona uma diretiva de cliente customizada para ser usada em arquivos .astro
.
Note que entrypoints de diretivas são agrupados somente através do esbuild e devem ser mantidos pequenos para que não deixem a hidratação de componentes mais lenta.
Exemplo de uso:
Você também pode adicionar tipos para as diretivas no seu arquivo de definição de tipos da sua biblioteca:
Opção injectRoute
Tipo: ({ pattern: string, entrypoint: string }) => void;
Uma função de callback para injetar rotas em um projeto Astro. Rotas injetadas podem ser páginas .astro
ou handlers de rotas .js
e .ts
.
injectRoute
recebe um objeto com um pattern
e um entrypoint
.
pattern
- aonde a rota deve ser inserida no navegador, por exemplo/foo/bar
. Umpattern
pode utilizar a sintaxe de caminho de arquivos do Astro para indicar rotas dinâmicas, por exemplo/foo/[bar]
ou/foo/[...bar]
. Note que uma extensão de arquivo não é necessária nopattern
.entrypoint
- apenas um especificador de módulo apontando para a página.astro
ou handler de rota.js
/.ts
que manipula a rota indicada nopattern
.
Exemplo de uso
Para uma integração projetada para ser instalada em outros projetos, utilize o nome do seu pacote para referenciar o entrypoint da rota.
O seguinte exemplo mostra um pacote publicado para o npm como @chique/painel
injetando uma rota de painel:
Opção injectScript
Tipo: (stage: InjectedScriptStage, content: string) => void;
Uma função de callback para injetar uma string de conteúdo JavaScript em todas as páginas.
O stage
indica como este script (o content
) deve ser inserido. Alguns stages permitem inserir scripts sem modificação, enquanto outros permitem otimizações durante a etapa de bundling do Vite:
-
"head-inline"
: Injetado em uma tag script no<head>
de cada página. Não é otimizado ou resolvido pelo Vite. -
"before-hydration"
: Importado no lado do cliente, antes do script de hidratação ser executado. Otimizado e resolvido pelo Vite. -
"page"
: Similar ahead-inline
, exceto que o script injetado é transformado por Vite e passa por bundle junto com quaisquer outras tags<script>
definidas dentro de componentes Astro na página. O script será carregado com um<script type="module">
no resultado final da página, otimizado e resolvido pelo Vite. -
"page-ssr"
: Importado como um módulo separado no frontmatter de cada componente de página Astro. Por conta desse stage importar seu script, a globalAstro
não está disponível e seu script será executado apenas uma vez quando oimport
for analisado pela primeira vez.O principal uso para o stage
page-ssr
é para injetar umimport
de CSS em cada página para ser otimizado e resolvido pelo Vite:
astro:config:done
Hook anterior: astro:config:setup
Próximo hook: astro:server:setup
quando estiver sendo executado no modo “dev”, ou astro:build
Quando: Após a configuração do Astro ter sido resolvida e outras integrações tiverem executado seus hooks astro:config:setup
.
Por que: Para obter a configuração final para uso em outros hooks.
Opção config
Tipo: AstroConfig
Uma cópia de somente leitura da configuração Astro suprida pelo usuário. Esta é resolvida após outras integrações serem executadas.
astro:server:setup
Hook anterior: astro:config:done
Próximo hook: astro:server:start
Quando: Logo após o servidor do Vite ser criado no modo “dev”, porém antes do evento listen()
ser disparado. Veja a API createServer do Vite para saber mais.
Por que: Para atualizar as configurações do servidor Vite e middleware.
Opção server
Tipo: ViteDevServer
Uma instância mutável do servidor Vite usado no modo “dev”. Por exemplo, esta é utilizada pela nossa integração Partytown (EN) para injetar o servidor Partytown como um middleware:
astro:server:start
Hook anterior: astro:server:setup
Próximo hook: astro:server:done
Quando: Logo após o evento listen()
do servidor ser disparado.
Por que: Para interceptar requisições de rede de um endereço específico. Se você pretende utilizar esse endereço para middleware, considere utilizar astro:server:setup
no lugar.
Opção address
Tipo: AddressInfo
O endereço, família e número de porta suprido pelo módulo Net do NodeJS.
astro:server:done
Hook anterior: astro:server:start
Quando: Logo após o servidor de desenvolvimento ser fechado.
Por que: Para executar quaisquer eventos de limpeza que você pode ativar durante os hooks astro:server:setup
ou astro:server:start
.
astro:build:start
Hook anterior: astro:config:done
Próximo hook: astro:build:setup
Quando: Após o evento astro:config:done
, porém antes da build para produção começar.
Por que: Para definir quaisquer objetos globais ou clientes necessários durante a build para produção. Esta também pode estender as opções de configuração de build na API de adaptadores.
astro:build:setup
Hook anterior: astro:build:start
Próximo hook: astro:build:ssr
Quando: Após o hook astro:build:start
, executado imediatamente antes da build.
Por que: Nesse ponto, a configuração Vite para a build foi completamente construída, logo essa é sua última chance de modificá-la. Isto pode ser útil para por exemplo sobrescrever alguma configuração padrão. Se você não tiver certeza se deve utilizar este hook ou astro:build:start
, então utilize astro:build:start
no lugar.
astro:build:generated
Hook anterior: astro:build:setup
Quando: Após uma build estática de produção terminou de gerar rotas e assets.
Por que: Para acessar rotas geradas e assets antes que artefatos de build sejam limpos. Este é um uso de caso bem incomum. Nós recomendamos usar astro:build:done
a não ser que você realmente precise acessar oss arquivos gerados antes da limpeza.
astro:build:ssr
Hook anterior: astro:build:setup
Quando: Após uma build SSR para produção tiver sido completada.
Por que: Para conseguir acesso ao manifesto de SSR e mapa dos pontos de entrada emitidos. Isso é útil quando se for criar builds SSR customizadas em plugins ou integrações.
entryPoints
mapeia uma rota de página para o arquivo físico emitido após a build.middlewareEntryPoint
é o caminho de arquivo no sistema do arquivo do middleware;
astro:build:done
Hook anterior: astro:build:ssr
Quando: Após a build para produção (SSG ou SSR) tiver sido completada.
Por que: Para acessar rotas geradas e assets para extensão (ex. copiar conteúdo do diretório gerado /assets
). Se você planeja transformar assets gerados, nós recomendados explorar a API de Plugins Vite e configurá-la via astro:config:setup
no lugar.
Opção dir
Tipo: URL
Um caminho de URL para o diretório final da build. Note que se você precisa de uma string de caminho absoluto válida, você deve utilizar o utilitário fileURLToPath
do Node.
Opção routes
Tipo: RouteData[]
Uma lista de todas as rotas geradas junto de seus metadados associados.
Você pode ver a referência completa do tipo RouteData
abaixo, mas as propriedades mais comuns são:
component
- o caminho do arquivo de entrada relativo à raiz do projetopathname
- a URL de saída do arquivo (undefined para rotas utilizando parâmetros[dinâmicos]
e[...spread]
)
Referência do tipo RouteData
Opção pages
Tipo: { pathname: string }[]
Uma lista de todas as páginas geradas. É um objeto com uma propriedade.
pathname
- o caminho finalizado da página.
Permitindo instalação via astro add
O comando astro add
permite que usuários facilmente adicionem integrações e adaptadores em seus projetos. Se você quiser que sua integração seja instalável com essa ferramenta, adicione astro-integration
no campo keywords
do seu package.json
:
Assim que você publicar sua integração no npm, executar astro add exemplo
irá instalar seu pacote com quaisquer dependências de pares especificadas em seu package.json
. Isso também irá adicionar sua integração ao astro.config
do usuário dessa forma:
Isso assume que a definição da sua integração é 1) uma exportação default
e 2) uma função. Garanta de que isso é verdade antes de adicionar a palavra-chave astro-integration
!
AstroIntegrationLogger
Uma instância do Astro logger, útil para escrever logs. Esse logger usa o mesmo nível de log configurado pelo CLI.
Métodos disponíveis para escrever no terminal:
logger.info("Mensagem")
;logger.warn("Mensagem")
;logger.error("Mensagem")
;logger.debug("Mensagem")
;
Todas as mensagens são precedidas com um rótulo que possui o mesmo valor da integração.
O exemplo acima registrará uma mensagem que inclui a mensagem info
fornecida:
Para registrar algumas mensagens com um rótulo diferente, use o método .fork
para especificar uma alternativa ao name
padrão:
O exemplo acima produzirá logs com [astro-format]
por padrão e [astro-format/build]
quando especificado:
Ordenação de Integrações
Todas as integrações são executadas na ordem em que são configuradas. Por exemplo, para o array [react(), svelte()]
na astro.config.*
de um usuário, react
será executado antes de svelte
.
Sua integração deve idealmente ser executável em qualquer ordem. Se isso não for possível nós recomendados documentar que sua integração precisar vir como primeira ou última no array de configuração integrations
do seu usuário.
Combinar integrações em presets
Uma integração também pode ser escrita como uma coleção de múltiplas, menores integrações. Nós chamamos estas coleções de presets. Ao invés de criar uma função de factory que retorna o objeto de uma única integração, um preset retorna um array de objetos de integração. Isso é útil para construir funcionalidades complexas a partir de múltiplas integrações.
Reference