Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Criar um pacote npm que funcione direto na importação nem sempre é trivial. Recentemente, tive que montar um pacote React e a maior dor foi o tempo de feedback na validação dos exports.
No meu caso, exportei os componentes no index.js, mas ao importar na aplicação, dava erro de módulo sem exports. O que percebi é que o problema costuma estar na configuração do pacote ou na forma como o build é feito.
Minha dica é testar o pacote localmente antes de publicar, usando comandos como npm link ou criando um projeto de teste. Assim, consegue validar o consumo real e ajustar a estrutura, como o caminho dos componentes e o arquivo de entrada. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
Na prática, o segredo é garantir que o pacote exporta tudo que precisa e que o build gera os arquivos corretos. A velocidade desse ciclo de feedback faz toda a diferença para evitar retrabalho e frustrações na hora da implantação. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
No meu time, já passei por isso. A dica que dou é sempre validar localmente antes de publicar, pra evitar esses erros de export. Às vezes o problema é a configuração do build mesmo.
Concordo com o Julião, o feedback rápido na validação local ajuda a evitar aquelas horas perdidas depois. Já tive que ajustar o caminho do index várias vezes.
O meu ponto é sempre testar o pacote com npm link. Assim, vejo se o problema é na exportação ou na build antes de publicar. Evita retrabalho depois.
Exato. E também revisar o package.json, especialmente os campos main e module. Às vezes, o problema está na configuração do ponto de entrada.