Como desenvolver melhor módulos JavaScript

Muitas pessoas já publicaram módulos JavaScript próprios no npm e, ao usar alguns módulos, eu frequentemente tenho a ideia de 'Este módulo é muito útil, mas seria melhor se pudesse xxx'. Portanto, neste artigo, vamos nos posicionar do ponto de vista do usuário do módulo e resumir como tornar o módulo mais útil.

Fornecer ES6 ponto de entrada do módulo

webpack e rollup suportam o ES6 Fazem otimizações estáticas do módulo (por exemplo, Tree Shaking e Scope Hoisting), todas lêem o campo module do package.json como entrada do módulo ES6 ponto de entrada do módulo, se não houver module, lê-se o campo main como entrada do módulo CommonJS. A prática comum é: usar ES6 Escrever código-fonte em sintaxe, e então usar ferramentas de empacotamento de módulos em conjunto com ferramentas de conversão de sintaxe para gerar módulos CommonJS e ES6 módulo, assim sendo possível fornecer tanto os campos main quanto module.

Fornecer arquivos de declaração de tipo do TypeScript

Se os usuários do TypeScript utilizarem seus módulos mas não fornecerem arquivos de declaração, eles terão que adicionar um trecho de código no projeto para evitar erros de compilação do TypeScript; Além disso, isso não é apenas amigável para os usuários do TypeScript, porque a maioria dos editores de código (Webstorm, VS Code, etc.) podem reconhecer declarações de tipos do TypeScript e, com base nisso, fornecer sugestões de código mais precisas e alertar o usuário quando ele passar a quantidade ou tipo de parâmetros incorretos.

A melhor prática é escrever seu módulo em TypeScript, que gerará automaticamente declarações de tipo na compilação. Além disso, você também pode consultar a documentação para manter manualmente um arquivo de declarações. Você pode adicionar um arquivo index.d.ts no diretório raiz do seu módulo ou declarar o campo typings no package.json para fornecer a localização do arquivo de declarações.

Permita que o módulo execute tanto no Node.js quanto no navegador

Você pode determinar se o módulo está executando no Node.js ou no navegador detectando se há uma variável global chamada window (por exemplo, !!typeof window) e usar diferentes maneiras de implementar suas funcionalidades.

Este método é comum, mas se o usuário usar uma ferramenta de empacotamento de módulos, isso levará a ambas as implementações Node.js e navegador serem incluídas no arquivo de saída final. Para esse problema, a comunidade de código aberto propôs adicionar o campo browser no package.json, e atualmente, o webpack e o rollup já suportam esse campo.

O campo browser tem duas maneiras de usar:

Forneça um caminho de arquivo para o campo browser como entrada de módulo para uso no navegador, mas note que o empacotador usará preferencialmente o caminho de arquivo especificado no campo browser como entrada de módulo, então o campo module será ignorado, o que levará o empacotador a não otimizar seu código. Detalhes podem ser encontrados neste problema.

Se você quiser substituir apenas alguns arquivos, você pode declarar um objeto.

Por exemplo, suponha que seu módulo contenha dois arquivos: http.js e xhr.js, o primeiro arquivo usa o módulo http do Node.js para fazer solicitações, e o outro usa a implementação XMLHTTPRequest do navegador para o mesmo propósito. Para usar o arquivo apropriado, o código do seu módulo deve sempre usar require(‘./path/to/http.js') e declare-o no package.json:

{
 "browser": {
  "./path/to/http.js": "./path/to/xhr.js"
 }
}

Dessa forma, quando seu módulo é usado em ferramentas de empacotamento, o empacotador só incluirá o código de xhr.js no arquivo de saída final.

Arme seu projeto com várias serviços

A maioria dos projetos JavaScript são de código aberto, e a comunidade de código aberto também oferece muitos serviços gratuitos para projetos de código aberto, que podem oferecer mais ajuda eficaz aos seus projetos, aqui estão alguns dos mais comuns.

O serviço mais usado em um projeto é o CI contínuo. O serviço de CI contínuo pode colocar tarefas como testes, verificação de estilo de código, empacotamento no servidor e executar automaticamente ao submeter código, comuns como Travis CI, CircleCI e AppVeyor. O Travis CI é gratuito para projetos de código aberto, fornecendo ambientes de execução Linux e OS X; o CircleCI é gratuito para projetos de código aberto e privados, mas há um limite mensal de uso. 15Restrição de tempo de execução de 00 minutos; AppVeyor oferece ambiente de execução Windows, gratuito para projetos de código aberto.

Após a execução dos testes, você ainda pode upload a cobertura de testes para o Coveralls. Este serviço permite que você navegue online na cobertura de testes do código.

Se você quiser que seu módulo seja testado plenamente em várias versões e plataformas de navegadores, você ainda pode usar Sauce Labs e BrowserStack, que são gratuitos para projetos de código aberto, mas requerem envio de e-mail para solicitação.

Por fim, o Shields IO oferece vários ícones, que podem fornecer muitas informações adicionais para seu projeto, incluindo, mas não se limitando a, número da versão npm, número de downloads, status de aprovação de testes, cobertura de testes, tamanho do arquivo, dependências expiradas, etc.

Aquilo é tudo o que compartilhamos com vocês sobre como desenvolver módulos JavaScript úteis. Se ainda tiver alguma dúvida, pode discutir na área de comentários abaixo. Obrigado pelo seu apoio ao tutorial Yell.

Declaração: O conteúdo deste artigo é extraído da Internet, pertence ao autor original, é contribuído e carregado voluntariamente pelos usuários da Internet, o site não possui direitos de propriedade, não foi editado manualmente e não assume responsabilidades legais relacionadas. Se você encontrar conteúdo suspeito de violação de direitos autorais, por favor, envie e-mail para: notice#oldtoolbag.com (ao enviar e-mail, substitua # por @ para denunciar e forneça provas relevantes. Aos descobrir, o site deletará imediatamente o conteúdo suspeito de violação de direitos autorais.)