Gerenciamento de dependência de JavaScript: npm vs. bower vs. volo [closed]


160

Como você compara npm, bowere volo?

Todos os três podem ser usados ​​para instalar dependências JavaScript para um projeto de interface do usuário. Eu entendo npmé mais específico do nó.

Então, quando usar o que?

npmainda está distante, mas bowere voloparecem estar a resolver exatamente o mesmo problema, embora eu não sou capaz de desenhar uma linha entre npme bower-volo.



1
Se você está aqui lendo esta pergunta e deseja uma resposta a partir de 2015, consulte minha resposta atualizada.
Gustavohenke

Respostas:


104

Uma descrição que melhor descreve a diferença entre npm e bower é: npm gerencia módulos JavaScript chamados packages e Bower gerencia componentes front-end (por exemplo, css, html e JavaScript) chamados componentes. O npm também é usado para instalar o bower. Aqui está um artigo abrangente sobre npm e bower (não cobre volo), que entra em muitos detalhes.


88
Esta não é uma descrição muito boa. O Npm certamente pode ser usado para instalar componentes front-end.
BT

Embora eu tenha notado que algumas bibliotecas "front-end" no npm são abandonadas em favor de seus colegas do caramanchão. Tomemos, por exemplo , o Ember , que não é publicado há um ano.
precisa saber é o seguinte

4
@Nate O nome é simplesmente onde começou. O NPM agora é um sistema de gerenciamento de pacotes de propósito geral. Uso regularmente o npm para instalar módulos front-end. Não há diferença no uso do NPM para módulos commonjs, vs amd, vs qualquer outra coisa. Você também pode usar o npm para módulos não-javascript. Portanto, isso simplesmente não é uma diferença entre npm e bower. Se você os chama de pacotes ou componentes, eles são os mesmos, pois são as duas coleções de arquivos arbitrários.
BT

2
Esta é uma resposta muito enganadora, considerando que o caramanchão não possui uma política para lidar com html, css e javascript. O npm também não possui política, exceto que quase tudo no npm é gravado para suportar pelo menos commonjs e, ocasionalmente, outros formatos. Você pode colocar html e css nos pacotes npm da mesma forma que pode com o bower. Existem muitos pacotes somente de front-end no npm, incluindo pacotes que incluem css e html.
Substack

3
Se você estiver usando o browserify , o npm é o gerenciador de pacotes perfeito. Eu não acho que importa qual gerenciador de pacotes você usa, mas eu pessoalmente ficaria com apenas um por projeto.
Eruant

72

caramanchão

Ainda é muito popular entre os desenvolvedores de front-end, apesar de ter muito poucos recursos. Todo pacote front-end está usando. Há também uma iniciativa de mesclar o pavilhão para o NPM .

O Bower é otimizado para o lado do cliente e suporta apenas árvores de dependência simples, ou seja, cada biblioteca deve ser usada apenas uma vez (já que é caro enviar versões diferentes da mesma biblioteca para o cliente), e as restrições de dependência devem ser resolvidas pelo usuário .

Você pode encontrar qualquer coisa relacionada ao front-end no registro do bower ( bower search <some keyword>) - na minha opinião, essa é a maior vantagem do bower em relação a outros gerenciadores de pacotes.

volo

Ainda não o uso há mais de 5 minutos em anos. Não sei, mas pelo que posso ver , inclui alguma ferramenta de construção, que é muito familiar para os usuários do Grunt.

npm

Sim, npm significa Node Package Manager. Mas hoje em dia você pode usá-lo para tudo; as pessoas não estão mais apenas npm installpensando nas coisas e esperando que funcionem apenas no ambiente do Nó. Por exemplo, existem muitos pacotes npm para o Twitter Bootstrap .

O Npm é otimizado para uso no servidor, com uma árvore de dependência aninhada. Cada dependência pode ter suas próprias dependências, que podem ter suas próprias e assim por diante. Essa versão de dependência eliminada entra em conflito, pois cada dependência pode usar sua própria versão, por exemplo, Underscore. No entanto, a próxima versão 3 do npm achatará a árvore de dependência :

Com o npm @ 3, o diretório node_modules ficará muito mais plano. Todas as suas dependências e a maioria das suas subdependências (e (sub) + dependências) ficarão próximas umas das outras no nível superior. Somente quando houver conflitos os módulos serão instalados em níveis mais profundos. Isso deve facilitar muito as coisas para os usuários do Windows.

Algumas vantagens que vejo ao usar o npm:

  • É usado por todos os outros gerenciadores de pacotes (componente, bower, volo, JSPM, etc);
  • Permite usar scripts de construção;
  • Muitas ferramentas estão disponíveis para a introspecção de pacotes baseados em npm

O npm é o gerenciador de pacotes do JavaScript.

captura de tela npmjs.com


Em fevereiro de 2013, minha opinião era a seguinte. Por favor, não leve mais em consideração.

npm

É melhor ficar com ele quando você estiver com um projeto Node, existem muito poucos projetos disponíveis para os navegadores também ...

caramanchão

Bower é o cara pop agora. Eles têm muitos projetos em andamento e os mantenedores do projeto gostam de mantê-los atualizados no registro do caramanchão ...

É uma pena que ele às vezes seja um pouco buggy.

volo

Eu não tentei volo por mais de 5 minutos desde então, mas pelo que pude ver, parece ser mais flexível do que caramanchão.

Um ponto negativo para o volo é que seus projetos estão muito desatualizados.


19
Existem milhares de módulos no npm que funcionam apenas em navegadores ou nos nós e nos navegadores. Muitos deles têm até crachás ci que informam exatamente em quais navegadores eles trabalham. Quase tudo no bower et all provavelmente está no npm.
substack

Eu não entendo a necessidade de projeto como ngBoilerplate ao uso pavilhão enquanto ele já depende npm para instalação
lolski

5
O que é um "cara pop"? É "pop" uma abreviação. para "popular"?
perfil completo de Bryan Oakley

4
Na sua tela, npm significa manual de planejamento nuclear;)
Jim Jones

24

Eles parecem estar resolvendo o mesmo problema, mas para diferentes ambientes / mundos. NPM para nodejs e volo, bower para o navegador.

A verdade é que você também pode usar o NPM para gerenciar javascript e css no navegador. Não há nada impedindo você de fazê-lo. Nesse sentido, o uso do NPM me parece mais natural do que ter que gerenciar duas ferramentas diferentes para o mesmo objetivo.

Parece que o caramanchão tem mais pacotes disponíveis, pelo menos para os mais populares. Mas em breve o jQuery também estará disponível no NPM diretamente e provavelmente todas as outras bibliotecas seguirão a mesma tendência.

Na minha opinião, como existem ferramentas como browserify e webmake por aí, que ajudam a usar módulos de nó no navegador, não há mais uma necessidade real de caramanchão ou volo , a menos que eles ofereçam outra coisa para você (um módulo específico existente apenas em seus registros).

Tanto o Volo quanto o Bower também são bons, mas do meu ponto de vista, se você já usa o NPM, talvez seja melhor cumpri-lo.

Observe que você pode usar o NPM para gerenciar as dependências do seu cliente, mesmo sem usar o browserify ou o webmake . Na maioria dos projetos em que estou trabalhando, após a instalação dos módulos npm, eu executo um script para implantá-los no local em que meu aplicativo cliente os utiliza. Às vezes eu uso o grunhido para concatenar esse arquivo com outros arquivos js e, às vezes, faço referência a ele diretamente dos arquivos de modelo dos meus aplicativos da web. De qualquer forma, essa é uma preferência pessoal. Outros poderiam achar o Bower ou o Volo mais fácil de usar, pois se encaixam mais naturalmente em seus fluxos de trabalho.


1
É bom ter soluções concorrentes para o mesmo problema. Alguma idéia de por que o yeomanprojeto escolheu criar um novo gerenciador de pacotes quando já tínhamos npm? (Era maduro, famoso e rico em recursos) Esse pensamento me faz sentir que ainda estou perdendo o ponto real.
Yugal Jindle

1
Na verdade, não, mas como você disse algumas vezes, é engraçado reinventar a roda, apenas porque você pode, e às vezes fazendo isso algumas melhorias são feitas ao tentar resolver o mesmo problema. Não é por isso que eles optam por criar um novo, além de facilitar o desenvolvimento de frontend pelos desenvolvedores para encontrar pacotes. Nem todos os desenvolvedores de front-end têm experiência com nós, acho que essa é a principal razão por trás de projetos como o Bower. Tente tornar mais fácil para os usuários que não são nós, só estou supondo aqui.
roy Riojas

Eu acho que eles queriam separar os problemas npmem favor da simplicidade do frontend. Daí para o desenvolvimento frontend.
Yugal Jindle

15

A grande vantagem do Bower sobre o NPM é que o gerenciamento de dependências impõe o uso de uma única versão de um componente (enquanto o NPM funciona tendo diferentes cópias / versões como subdependências de diferentes módulos). Isso é MUITO BOM, pois evita que o javascript do lado do cliente fique inchado por precisar incluir várias cópias de um componente em versões diferentes. A inclusão de várias cópias de um módulo é fundamental para o funcionamento do gerenciamento de dependências do NPM e, portanto, o NPM é totalmente inadequado para o gerenciamento de pacotes do lado do cliente.

Uma consequência do exposto acima é que os mantenedores e consumidores de pacotes de caramanchão precisam ter mais cuidado em manter seus números de versão de dependência para evitar conflitos, mas é um preço que vale a pena pagar. E acho que os módulos NPM geralmente são desleixados na emissão de versões principais, secundárias e de patches, portanto o gerenciamento de dependências do NPM também não é exatamente um leito de rosas.


3
Isso só é verdade se você estiver exibindo seu código de front-end diretamente da pasta na qual o gerenciador de pacotes colocou esses arquivos. No meu caso, eu tenho o script de construção para processar os arquivos less / js ou o browserify para criar um pacote desses arquivos. Portanto, isso não é realmente um grande problema no meu caso. O código que está sendo distribuído sempre tem as versões corretas, mesmo quando outros subcomponentes podem ter duplicatas durante o desenvolvimento e nunca chegam à produção.
Roy riojas

mesmo se você estiver solicitando inadvertidamente (como subdependências) duas versões diferentes da mesma dependência? Eu acho que, neste caso, você está errado
whereesrhys

Normalmente eu não preciso de módulos que não controlo, então eles sempre serão os corretos ... se, inadvertidamente, um módulo tentar exigir um determinado módulo dentre os shimmed, a construção falhará. Nenhum ponto em usar pavilhão no meu caso nenhum benefício adicionado
roy riojas

Portanto, o npm só pode ser dito com segurança para evitar a duplicação de módulos no código do lado do cliente se você tiver controle de toda a sua árvore de dependência. Esse certamente não é o caso da grande maioria das coisas em que trabalho e provavelmente não para a maioria dos projetos que usam um gerenciador de dependências para incluir módulos do lado do cliente.
wheresrhys

1
A menos que você esteja trabalhando em mashups, sua árvore de dependência não será tão complicada, pelo menos para o código de terceiros. A maioria das bibliotecas js exporta uma única global, portanto, usando o browserify-shim, você pode garantir que pode usá-las no escopo global, portanto, sempre uma versão que você controla. O que quero dizer é que você pode conseguir o mesmo sem a necessidade de outro gerenciador de pacotes em cima de um que você já possui. No final, pode ser uma questão de preferências. Sempre há compromissos a serem feitos.
Roy riojas

5

Eu sei que isso não está no escopo da pergunta, mas há outra alternativa também. Jam JS - http://jamjs.org/ Uma coisa interessante é que ele possui recursos de grunhido no jam:

jam compile output.js

Alguém deve criar outro gerenciador de pacotes e nomeá-lo: yapm :)


5
Seu desejo é atendido: github.com/rlidwka/yapm : P
alex

1
bem, eu estava pensando no gerenciador de dependências do lado do navegador, mas acho que este trabalho para os dois: p É por isso que não consigo fazer startups, todas as minhas idéias já foram pensadas.
Bruce Lim

@BruceLim sim, toda vez que achamos que temos uma boa ideia, sempre há outras pessoas que já a entenderam.
Evan Hu
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.