O npm foi projetado para ser usado também para gerenciar dependências do lado do cliente?

4

Estou usando o Composer para gerenciar minhas dependências do PHP e ficaria feliz em fazer o mesmo com minhas dependências de JS.

Eu tropecei no NPM para Node.js , e estou querendo saber se ele deve ser usado como um gerenciador de dependências do lado do cliente também.

Por exemplo, talvez eu queira gerenciar as dependências da biblioteca do lado do cliente na pasta /public/vendor/ do meu aplicativo e instalar / atualizar essas dependências como faria com composer install ou composer update para PHP.

É npm para mim?

    
por Benjamin 14.02.2013 / 14:12

4 respostas

4

Não diretamente, embora alguns dos pacotes que você instala via npm (por exemplo, socket.io) emitam bibliotecas Javascript do lado do cliente.

Existe outra ferramenta chamada Bower , que é projetada para bibliotecas do lado do cliente. Pode haver outros, mas esse é o que eu mais mencionei. É usado internamente pela ferramenta Yeoman do Google para as bibliotecas do lado do cliente.

    
por 19.02.2013 / 16:00
4

Há um caso entusiasmado feito aqui , que termina com o resumo:

All package managers do relatively the same thing. Move files. Pick a package manager on how well it does that. All build tools do relatively the same thing. Transform files. Pick your build tools on how well they do that. If you're not using npm now solely because someone told you it isn't for client side. Slap them and say, "npm all the things."

A minha própria maneira de ver: o cliente e o nó podem, muitas vezes, usar o código comum. Portanto, um dia , será sensato que os projetos de cliente e nó ocupem o mesmo repositório. Qualquer que seja o repositório, ele (idealmente) ganhará massa crítica e substituirá todos os outros repositórios de clientes e nós. E como o npm já está tão bem estabelecido, por que não deveria se tornar aquele repositório?

    
por 02.08.2013 / 15:48
2

O NPM foi projetado especificamente para gerenciar pacotes JavaScript em execução no Node.js (lado do servidor). Agora, quando há ~ 80000 pacotes no npm repositório público surgiram alguns problemas com o design original (por exemplo, o problema do espaço de nomes simples) e JavaScript alternativo gerenciadores de pacotes apareceram.

Um que, até recentemente, visava resolver todos os problemas de dependência do cliente / lado / cliente JavaScript do servidor é o gerenciador de pacotes component usando o repositório GitHub e seu namespace.

Este artigo estava no início: link

Existem atualmente ~ 2500 pacotes no repositório público de componentes .

Uma pequena comparação com outros gerenciadores de pacotes do JavaScript está disponível aqui: link

    
por 06.07.2014 / 15:32
1

Há uma postagem recente sobre isso na NPM: link

“npm is only for server-side JavaScript!”

Also not true. Your package can contain anything, whether it’s ES6, client-side JS, or even HTML and CSS. These are things that naturally turn up alongside JavaScript, so put them in there.

...

If it’s JavaScript-related, host it in npm. Once they are available, use ecosystems to create “mini-registries” within the global one, complete with custom search indexing and display characteristics.

Então, sim. É muito bom colocar coisas JavaScript do lado cliente no NPM, e elas melhorarão o suporte para isso.

    
por 12.03.2015 / 05:17