Implantação no Netlify
Publicar a saída construída do Chinaski no Netlify é possível (o builder já emite regras de redirecionamento em formato Netlify), mas o repo não embarca nenhum pipeline específico do Netlify, então esta página documenta a mecânica verificada e as duas ressalvas a conferir antes de enviar para lá.
O que o builder produz
A cada build, a raiz da saída ganha um arquivo _redirects contendo suas regras de redirecionamento no próprio formato do Netlify: linhas simples de slug-antigo slug-novo codigo-status, ligadas aos redirecionamentos que você gerencia no admin (o build log diz “N Netlify redirect rule(s) written” quando há regras). Esta é a principal superfície de compatibilidade com hosts estáticos: construa, então envie o diretório, e seus redirecionamentos simples de caminho funcionam como estão.
Todo o resto são arquivos ordinários: árvores de saída por idioma com arquivos index.html, as peças de PWA (sw.js, manifest, página offline), sitemaps e feeds, e a árvore da pasta de mídia.
Ressalva 1: a linha de domínio canônico
Quando uma URL de Site está definida, o builder também acrescenta uma regra de domínio canônico ao _redirects que aplica 301 ao host alternativo www/domínio-nu para o seu canônico. O marcador final ! é sintaxe de redirecionamento do Caddy, não do Netlify. Se você faz deploy em um parser estrito do Netlify, revise aquela linha gerada antes de enviar: descarte-a ou reescreva-a conforme a gramática de regras de redirecionamento do Netlify. (O resto do _redirects, com pares simples de caminhos e códigos de status numéricos, está no formato padrão.)
Ressalva 2: redirecionamentos com padrão não estão no arquivo
Redirecionamentos com padrão (curingas com substituições) deliberadamente nunca são escritos no _redirects, pois o formato simples de arquivo não consegue expressá-los com segurança. Se o seu site depende de regras com padrão, elas precisam ser implementadas no host em vez de viajar escondidas no arquivo.
Alcance de hospedagem estática: o que um host puramente estático não vê
Duas funcionalidades do CMS não existem na saída estática e precisam alcançar o próprio CMS:
- Submissões de formulários fazem POST para
/forms/<slug>no CMS. Em um host estático não há destino, a menos que você defina a URL base do CMS, caso em que os shortcodes[form:slug]incorporados são renderizados como iframes apontando para o formulário hospedado no CMS, e as submissões chegam onde o CMS é alcançável. - Downloads de documentos são servidos dinamicamente (contagem de downloads e estado de publicação): um deployment apenas estático não pode servi-los; a funcionalidade de documentos exige a rota de proxy dinâmica.
Em resumo: a hospedagem Netlify é viável para sites puramente de conteúdo; sites pesados em formulários ou documentos precisam do CMS alcançável (via URL base) ou de outro modelo de hospedagem.
Pipelines
Não há um alvo de deploy “push para o Netlify” embutido: os deploys de saída embutidos são rsync-por-SSH e buckets compatíveis com S3 (Settings → Deploy). Para levar builds ao Netlify você liga o seu próprio transportador (CLI/config do netlify, um pipeline baseado em repo, ou upload roteado por script) disparado após cada build. O diretório de saída mais o _redirects é o artefato autocontido, reemitido completamente a cada build.
Ressalvas de modo de idioma: um site em deploy no modo de URL por subdomínio precisa de alvos de deploy separados por subdomínio de idioma; sites em modo path fazem deploy como uma árvore única.
Uma nota sobre headers
Os comportamentos de cache nos exemplos estáticos embarcados (cache curto em HTML, imutável nas fontes .woff2, no-cache no sw.js) são implementados nos arquivos de exemplo de reverse-proxy para o seu próprio servidor, não embutidos no build. Em um host estático gerenciado, regras de header são uma preocupação de configuração do host: aplique-as lá conforme o sistema de regras do seu provedor.