Saída gerada
just build executa, dentro da imagem Docker de desenvolvimento, exatamente:
- validar as dependências locais habilitadas: Tailwind (
node_modules/.bin/tailwindcss), Pagefind, Mermaid CLI/Chromium e Shiki/Node.js; - limpar ou criar
dist/; - resolver e publicar fontes declaradas, quando configuradas (Google ou locais);
- compilar e hashear
Core/Assets/main.csse cada entrada CSS do usuário, além de publicar JavaScript e arquivos literais; - publicar Reveal.js localmente, quando
feature.revealjsestiver ligado; - publicar o Remix Icon localmente, quando
feature.remixiconestiver ligado; - validar e copiar favicons;
- descobrir e renderizar páginas, convertendo Mermaid para SVG inline e aplicando Shiki aos fences conhecidos quando habilitados;
- gerar o índice Pagefind em
pagefind/, quandofeature.pagefindestiver ligado; - publicar as fontes
.mdxhabilitadas por Collection; - gerar feeds Atom e RSS habilitados por Collection;
- gerar
sitemap.xml; - gerar
robots.txt; - gerar
llms.txte os arquivosllms_fullhabilitados por Collection; - validar os links
<a href>internos contra os arquivos publicados e suas âncoras quando o destino é HTML; - gerar capas PNG de 1200×630 e comprimi-las sem perda com OptiPNG;
- 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.<hash>.<ext>.
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.