Build & Assets

O Seed oferece controle granular sobre como CSS, JS e HTML são entregues — desde assets externos servidos via URL até conteúdo injetado inline no HTML. Tudo configurável no seed.yaml.

Configuração no seed.yaml

```yaml
theme: seed-theme    # tema em themes/seed-theme/
js: file          # inline | file (padrão: file)
css: file         # inline | file (padrão: file)
minify: false     # minificar HTML/CSS/JS (padrão: false)
optimize-css: true    # gerar CSS Tailwind otimizado no build (padrão: true)
optimize-images: true # gerar srcset/webp responsivo no build (padrão: true)
```

Modo file vs. inline

Os modos js e css controlam como os assets do tema são entregues nas páginas.

Modo file (padrão)

Assets são referenciados por URL — o browser os baixa separadamente e pode cacheá-los:

```html
<link rel="stylesheet" href="static/seed-ui.css">
<script src="static/seed-ui.js"></script>
```

Ideal para produção — o browser cacheia os arquivos e não os baixa novamente entre páginas.

Modo inline

O conteúdo do arquivo é injetado diretamente no HTML:

```html
<style>/* conteúdo de seed-ui.css */</style>
<script>/* conteúdo de seed-ui.js */</script>
```

Ideal para páginas únicas ou distribuição como arquivo único — zero requests externos para CSS/JS.

Combinando modos

Os modos js e css são independentes — você pode combinar livremente:

```yaml
js: inline    # JS inline para interatividade sem request extra
css: file     # CSS por arquivo para cache eficiente
```

Scripts de componente

Scripts de componente (.js ao lado do .yaml) são sempre injetados inline, independente do modo js configurado. Eles só aparecem nas páginas onde o componente é usado.

Bundle de JavaScript no build

No seed build, o Seed concatena todo o JS do tema (themes/<nome>/assets/*.js) com os scripts de componente usados em dist/static/seed.<hash>.js — um único arquivo, com hash de conteúdo no nome:

• Substitui as tags <script src="..."> individuais de cada arquivo do tema por uma única referência ao bundle
• O hash muda sempre que o conteúdo muda — nunca serve JS desatualizado de um cache antigo do browser
• Uma cópia sem hash (seed.js) é mantida para compatibilidade com HTML já cacheado antes dessa mudança

Não requer configuração — acontece automaticamente em todo seed build. No seed dev, os scripts continuam sendo servidos individualmente (sem bundle), para facilitar debug.

Minificação

Com minify: true, o output do build passa por minify-html — remove espaços, comentários e otimiza o HTML:

```yaml
minify: true
```

O que é minificado:

• HTML — espaços e comentários removidos
• CSS inline — compactado quando injetado via css: inline
• JS inline — compactado quando injetado via js: inline

Assets estáticos

Assets do projeto (src/assets/) e do tema (themes/<nome>/assets/) são servidos em /static/...:

• Dev: servidos diretamente das pastas, sem copiar para dist/
• Build: copiados para dist/static/
• Prioridade: src/assets/ sobrescreve assets do tema com o mesmo nome

Referenciando assets no front matter

```yaml
---
title: Minha Página
css: /static/seed-ui.css
js:
  - /static/seed-ui.js
  - /static/meu-script.js
---
```

Otimização de imagens (srcset)

No seed build, o Seed gera automaticamente variantes responsivas para imagens locais (.png, .jpg, .jpeg, .webp) referenciadas em <img> dentro de dist/, e adiciona srcset/sizes — sem precisar declarar nada no .seed:

```html
<!-- antes -->
<img src="static/img/capa.jpg">

<!-- depois do build -->
<img src="static/img/capa.jpg"
     srcset="capa-480w.webp 480w, capa-768w.webp 768w, capa-1280w.webp 1280w"
     sizes="(max-width: 768px) 100vw, 768px">
```

• Larguras geradas: 480px, 768px, 1280px — só as estritamente menores que a imagem original (nunca faz upscale)
• Cada variante é salva como .webp ao lado da imagem original (capa-480w.webp), sem sobrescrever o arquivo fonte
• Se a imagem já tem atributo width, o sizes usa esse valor como referência; senão usa um padrão de 768px
• Imagens remotas (http(s)://), data: e blob: são ignoradas — só imagens locais em dist/ são processadas
• Um <img> que já declara srcset manualmente não é tocado

Dependência opcional (Pillow)

A geração de variantes usa a biblioteca Pillow, instalada via extra opcional:

```bash
pip install seed-html[images]
```

Sem o Pillow instalado, o build segue normalmente — apenas exibe um aviso e não gera srcset (o <img> original permanece intacto, sem erro).

Cache entre builds

Variantes já geradas ficam em cache local (.seed-cache/images/, chaveado pelo hash do conteúdo da imagem fonte) — rodar seed build de novo, ou apagar dist/, não força recodificar as mesmas imagens.

Desativando

```yaml
# seed.yaml — desativa para todo o projeto
optimize-images: false
```

Ou, só para um build específico:

```bash
seed build minha-pasta --no-optimize-images
```

Tailwind CSS

No desenvolvimento

No seed dev, o Tailwind é carregado via CDN automaticamente — nenhuma configuração necessária:

```html
<script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>
```

O CDN escaneia o DOM e gera o CSS dinamicamente no browser. Ideal para desenvolvimento: funciona sem instalar nada.

No build

No seed build, o Seed substitui automaticamente o CDN por CSS otimizado gerado pelo Tailwind CLI. O processo acontece em três etapas:

1. Todos os arquivos HTML são gerados em dist/
2. O Tailwind CLI escaneia os HTMLs e gera apenas as classes utilizadas
3. O <script> do CDN é removido e substituído pelo CSS gerado, seguindo o modo configurado em css

O comportamento segue o css configurado no seed.yaml:

```yaml
css: inline   # CSS injetado como <style> em cada página
css: file     # CSS salvo em dist/static/tailwind.css e referenciado via <link>
```

Para usar o build otimizado, é necessário ter Node.js instalado — o Seed usa npx @tailwindcss/cli automaticamente, sem instalação prévia do pacote.

Comparativo

Build incremental

Todo seed build compara o dist/ gerado com o dist/ da execução anterior, arquivo por arquivo (por hash de conteúdo):

• Arquivo sem mudança de conteúdo — a data de modificação (mtime) é restaurada para o valor anterior, mesmo que o build tenha reescrito o arquivo. Isso evita que ferramentas de deploy baseadas em mtime (ex: rsync) reenviem arquivos que não mudaram de fato
• Arquivo que não foi mais gerado (fonte renomeada ou apagada) — é removido de dist/, junto com diretórios vazios resultantes

Isso é automático, sem configuração — o resumo aparece ao final do build:

```
Build complete: 42 HTML file(s), 1671 KB total → dist/ (0.69s · 8 unchanged · 0 pruned)
```

Feito com ❤️ e Seed