Pronto para Produção
Vize ainda é experimental.
Isso não é um aviso para se esconder. É uma descrição da fase atual.
O objetivo é passar de um projeto experimental para uma cadeia de ferramentas pronta para produção. O único caminho honesto é validação do mundo real e feedback da comunidade.
Aplicativos de brinquedo não são suficientes
Pequenos exemplos são úteis para desenvolvimento.
Eles nos permitem isolar uma regra, uma transformação, um mapa de fonte, um único comportamento de compilador.
Mas projetos de produção Vue não são exemplos pequenos. Eles contêm:
Layouts incomuns de pacotes
padrões antigos e novos do Vue juntos
Aliases de caminho
Autoimportações
Macros
Pré-processadores de estilo
componentes profundamente aninhados
Arquivos gerados
Convenções estruturais
Comportamento dos plugins
Problemas específicos de plataforma
Uma cadeia de ferramentas que só passa exemplos de brinquedos não está pronta para produção.
É um protótipo com uma demonstração legal.
Varreduras Exaustivas Importam
O trabalho entediante é o que mais importa aqui.
O Vize precisa rodar por projetos reais arquivo por arquivo, erro por erro, diagnóstico por diagnóstico, snapshot por snapshot.
Isso significa verificar:
Saída da build
Saída de fiapos
Saída de verificação de tipo
Estabilidade do formador
Locais de origem
Resolução de caminho
Comportamento do dev-server
Comportamento da construção em produção
Diferenças entre Windows e Unix
Esse tipo de trabalho exaustivo não é glamouroso.
Mas é o trabalho que transforma "funciona com o exemplo" em "sobrevive a um repositório real."
O feedback da comunidade é a principal contribuição
A comunidade encontrará casos que o mantenedor não imaginou.
Isso não é um fracasso. Esse é o ponto.
Todo relatório real é valioso:
um projeto que não compila
um falso positivo que torna uma regra inutilizável
um diagnóstico que é tecnicamente correto, mas pouco útil
um penhasco de performance em CI
Uma convenção macro ausente
um problema de caminho apenas para Windows
um mapa de origem que aponta um token para fora
Esses relatos não são interrupções. Eles são o conjunto de dados.
A resposta correta é transformá-los em fixatures, testes, snapshots e benchmarks.
Pronto para produção é um comportamento, não um rótulo
"Pronto para produção" não é algo que um projeto se torna porque o README diz isso.
É um comportamento ao longo do tempo:
Solicitações de correção se tornam testes de regressão
Benchmarks cobrem fluxos de trabalho reais
Notas de lançamento explicam o risco
Mudanças que quebram são intencionais
CI representa plataformas suportadas
Diagnósticos permanecem estáveis o suficiente para automação
Os usuários podem prever o que a ferramenta fará
Isso é especialmente importante para o Vize porque ele toca em muitas camadas. Um descompasso do compilador, falso positivo no linter, descompasso de verificação de tipo ou mapa de origem incorreto podem danificar a confiança de maneiras diferentes.
A barra é alta porque a área de superfície é alta.
Por que a independência ajuda aqui
Ferramentas oficiais precisam de um tipo diferente de cautela.
Eles carregam imediatamente as expectativas do ecossistema. Eles não podem experimentar de forma agressiva demais sem afetar uma grande base de usuários.
Vize é independente, e isso lhe dá espaço para se mover rapidamente:
tente mudanças na arquitetura
reescrever internos
Adicionar diagnósticos rigorosos
testar backends alternativos do compilador
remover abstrações fracas
Gargalos de desempenho na Chase
Aprenda com relatórios da comunidade sem prometer estabilidade instantânea
Essa velocidade é útil, mas traz responsabilidade.
O projeto precisa ser claro quanto ao seu status e levar a validação a sério.
O roteiro é moldado por feedback
O caminho para a prontidão para produção não é apenas uma lista de recursos.
É um ciclo de retroalimentação:
Administre o Vize em projetos reais.
Registre cada falha como teste ou fixação.
Corrija o modelo subjacente, não apenas o sintoma.
Compare comportamento com ferramentas oficiais.
Mantenha o desempenho visível.
Repita até que os casos surpreendentes se tornem entediantes.
É assim que uma cadeia de ferramentas cresce.
Não fingindo estar acabado.
Deixando que código real, usuários reais e restrições reais moldem o trabalho até que o sistema se torne confiável.