Pular para o conteúdo
Navegar na documentação

Saída gerada

just build executa, dentro da imagem Docker de desenvolvimento, exatamente:

  1. validar as dependências locais habilitadas: Tailwind (node_modules/.bin/tailwindcss), Pagefind, Mermaid CLI/Chromium e Shiki/Node.js;
  2. limpar ou criar dist/;
  3. resolver e publicar fontes declaradas, quando configuradas (Google ou locais);
  4. compilar e hashear Core/Assets/main.css e cada entrada CSS do usuário, além de publicar JavaScript e arquivos literais;
  5. publicar Reveal.js localmente, quando feature.revealjs estiver ligado;
  6. publicar o Remix Icon localmente, quando feature.remixicon estiver ligado;
  7. validar e copiar favicons;
  8. descobrir e renderizar páginas, convertendo Mermaid para SVG inline e aplicando Shiki aos fences conhecidos quando habilitados;
  9. gerar o índice Pagefind em pagefind/, quando feature.pagefind estiver ligado;
  10. publicar as fontes .mdx habilitadas por Collection;
  11. gerar feeds Atom e RSS habilitados por Collection;
  12. gerar sitemap.xml;
  13. gerar robots.txt;
  14. gerar llms.txt e os arquivos llms_full habilitados por Collection;
  15. validar os links <a href> internos contra os arquivos publicados e suas âncoras quando o destino é HTML;
  16. gerar capas PNG de 1200×630 e comprimi-las sem perda com OptiPNG;
  17. pré-comprimir a saída textual com Brotli e gzip.

O build pode manter artefatos derivados fora de dist/, em storage/framework/build-cache/, para acelerar execuções seguintes. Esse diretório é cache de execução e não faz parte da publicação; dist/ é sempre reconstruído e continua contendo somente a saída atual do conteúdo.

Estrutura representativa:

O arquivo de fonte do Remix Icon segue o padrão fonts/remixicon.&lt;hash&gt;.&lt;ext&gt;.

dist/
├── index.html
├── 404.html
├── pagefind/
│   ├── pagefind.js
│   ├── pagefind-component-ui.js
│   └── ...fragmentos do índice...
├── cover.png
├── 404/
│   └── cover.png
├── sobre/
│   ├── index.html
│   └── cover.png
├── assets/
│   ├── main.<hash>.css
│   ├── css/
│   │   └── app.<hash>.css
│   ├── js/
│   │   └── app.<hash>.js
│   ├── fonts.<hash>.css
│   ├── fonts/<hash>.woff2
│   ├── remixicon/
│       ├── remixicon.<hash>.css
│       └── fonts/remixicon.<hash>.<ext>
│   └── reveal/
│       ├── reveal.<hash>.mjs
│       └── reveal.<hash>.css
├── favicon.ico
├── icon.svg
├── apple-touch-icon.png
├── exemplo-publico.txt
├── sitemap.xml
├── robots.txt
├── llms.txt
└── manual/
    ├── atom.xml             # somente com feed: true
    ├── rss.xml              # somente com feed: true
    ├── llms-full.txt
    └── primeiro.mdx

Uma página MDX com type: presentation gera as duas variantes abaixo; a versão artigo permanece a rota canônica e vertical:

dist/apresentacao/index.html
dist/apresentacao/slides.html

slides.html usa o layout de apresentação e o runtime Reveal.js publicado no manifesto. A variante recebe noindex,follow e canonical para /apresentacao/. Em projetos com site.basePath, o prefixo é aplicado tanto à rota quanto aos assets.

O guia Criar e personalizar apresentações explica como a fonte MDX vira as duas variantes, como testar os hashes e como interpretar a saída em dev, build e serve.

Quando uma Collection declara mdx_source: true, cada item indexável recebe uma cópia literal da fonte original ao lado da rota HTML. Por exemplo, /manual/primeiro gera dist/manual/primeiro.mdx; o arquivo mantém o front matter, Markdown, HTML e componentes Blade, mas não executa Blade. As fontes MDX também recebem .br e .gz porque são tratadas como saída textual. Itens noindex não são publicados, e uma Collection habilitada não pode conter itens Blade.

Cada HTML, CSS, SVG, XML, TXT, MDX, JSON, JavaScript, source map ou web manifest também recebe arquivos adjacentes .br e .gz, sem remover o original. WOFF2, PNG e ICO já são formatos comprimidos e não recebem sidecars.

Rotas normais usam <rota>/index.html; a home usa index.html; páginas de erro usam arquivos planos como dist/401.html, dist/403.html, dist/429.html e dist/500.html. A convenção aceita qualquer código numérico HTTP de três dígitos entre 100 e 599, portanto códigos 4xx e 5xx são publicados sem alteração, por exemplo Content/Pages/_errors/418/ gera dist/418.html. Toda rota recebe capa, inclusive a home, rotas noindex e páginas de erro, salvo quando declara cover: false. O template default é Content/Views/covers/cover.blade.php; cover: covers.nome seleciona outra view em Content/Views. Templates são renderizados como HTML independente e convertidos em PNG de 1200×630; a criação de uma cover com componentes e CSS embutido está descrita em Personalizar templates, componentes e covers.

O HTML das páginas é renderizado com os CSSs publicados e hasheados e gravado diretamente. O HTML das covers é convertido pelo Chromium Headless enquanto um php -S temporário serve dist/; assim CSS e fontes relativos, inclusive os do Remix Icon e os declarados em $fontStylesheet, são resolvidos sem rede externa. Templates de cover recebem também $fontPreloads para preloads dos WOFF2 publicados. Como o documento temporário usa file://, o servidor libera CORS para esses assets. As URLs de assets preservam site.basePath e o servidor é encerrado ao final da geração. Um pós-processador acrescenta site.basePath a URLs root-relative das páginas e normaliza rotas para a barra final. Somente links marcados com data-prefetch podem gerar <link rel="prefetch">; o atributo é removido, rotas inválidas/externas/atuais são ignoradas, os URLs são deduplicados e o limite é dois por página. A paginação do manual marca anterior e próxima.

Sitemap exige metadata sitemap em toda rota indexável. Robots e llms.txt são arquivos globais; feeds Atom/RSS, consolidadores llms_full e fontes .mdx são saídas opt-in de Collections. As regras detalhadas estão em Metadata e Collections.

A validação de links percorre os HTMLs publicados e falha o build se um <a href> local não resolver para um arquivo publicado. Isso inclui documentos HTML, feeds XML e fontes MDX. Fragmentos são verificados somente em destinos HTML, e precisam corresponder a id ou a[name]. A validação aceita caminhos relativos, URLs no domínio configurado e site.basePath; links externos e os esquemas mailto:, tel:, javascript: e data: não são verificados. O erro informa a página de origem e o destino ou âncora inválidos.

Uma exceção interrompe os estágios seguintes e pode deixar saída parcial. A validação do Tailwind acontece antes de qualquer limpeza; se ele estiver ausente ou sem permissão de execução, o erro informa o caminho, @tailwindcss/cli ^4.0.0 e sugere npm ci/npm install. As demais dependências fatais incluem os favicons, a página /404, cada template de cover selecionado, metadata sitemap, chromium, optipng, brotli e gzip. Fontes configuradas exigem rede apenas quando não existe cache válido ou quando --refresh-fonts é usado.

Ausência de histórico Git gera warnings e fallback para mtime. Warnings não mudam o código de sucesso.

A imagem builder contém runtime, dependências, Core/, blog, Tailwind, Chromium e ferramentas de rendering; não contém Content, Tests, public ou dist. Seu processo usa o usuário app, com UID/GID configuráveis na construção e default 1000.