Não tenho certeza se isso é viável ou se pertence ao repositório Node.js.

O que? Por que

Freqüentemente, há casos em que certas dependências requerem configurações específicas de compilação para funcionar corretamente em um ambiente geral (por exemplo).

Esta configuração pode ser uma configuração Babel, uma configuração Webpack ou algo personalizado apenas para aquele pacote.

Como está atualmente, não existe uma maneira padronizada de configurar pacotes.

Algumas pessoas usam uma convenção onde colocam um campo em package.json com o nome do pacote, e um pacote pode ler isso. Mas não parece padrão o suficiente.

Quando

Quando um pacote precisa de configuração personalizada para tempo de execução ou tempo de construção.

Onde

Quão

Às vezes, o JavaScript precisa de etapas de construção para certos casos. Este recurso de configuração teria uma opção opcional de "dependências de construção" que pode ser passada para qualquer pacote (se eles constroem módulos nativos ou apenas transpilam JavaScript para uma forma inferior).

Dependendo da configuração, um pacote pode precisar de certas dependências que de outra forma não seriam necessárias (por exemplo, dependências de compilação).

Portanto, o sistema de pacotes seria inteligente o suficiente, pois se um usuário tiver certa configuração de pacote, ele pode determinar quais dependências adicionais instalar.

Talvez esse recurso precise apenas ser expandido do sistema de módulo nativo existente para o sistema JavaScript geral (de uma forma fácil de usar, os módulos nativos são complicados).

Isso também pode ser muito útil para coisas como dependências opcionais. Seria fácil, com config, especificar que uma biblioteca use (por exemplo) three vez de babylonjs . Isso faria com que a dependência apropriada fosse instalada. É semelhante às dependências de pares, mas mais fácil, e um determinado pacote que depende de dependências opcionais teria uma maneira padrão de acessar a API de configuração de maneira confiável para determinar se certas condições são especificadas (atualmente é complicado, e qualquer travessia de cystom de node_modules não é padrão nesses casos).

Comportamento Atual

• n / D

Comportamento esperado

• coberto acima em um alto nível

Como outro exemplo, às vezes os consumidores de pacote precisam consumir o código-fonte do pacote em vez da saída compilada usual para compilar o código de maneiras diferentes (normalmente, para mim, tenho vontade de fazer isso com o Webpack).

Em geral, há problemas com esse tipo de coisa, que o NPM até agora não oferece uma maneira comum de lidar.

Quem

autores de pacotes e seus usuários

Referências

• n / D