Migrando do Bower para Yarn #619
Comments
|
Acredito que não faça muito sentido a substituição pro Yarn. Caso o projeto tenha um package.json, migra tudo do bower pra ele, o yarn entraria pra substituir o npm. Utilizar um module bundler tem um overhead maior, exige a mudança numa série de arquivos pra tudo ficar redondinho e como você aparentemente não tem muito tempo.. Tenta fazer a mudança de forma gradativa, uma coisa de cada vez. |
|
@thulioph valeu pela contribuição. Mas me permita discordar: acredito que faz todo sentido substituir pro Yarn. Sem entrar em maiores detalhes, o próprio pessoal do Bower recomenda essa migração. Talvez eu não tenha formulado o tópico da melhor forma, mas minha intenção era apenas saber se existe algo análogo ao wiredep para o Yarn. |
|
Wiredep não é um plugin pro Grunt / Gulp? (me corrija se eu estiver errado pfv) Acredito que não muda nada você usando o Yarn ou Npm já que quem levanta o wiredep é um task runner. O yarn faz mais do que gerenciar pacotes? Agora fiquei na dúvida 🤔 |
|
Eu troquei o Bower pelo Yarn em alguns projetos, mas logo depois larguei o Yarn para ficar somente com NPM. Eu gostava da proposta do Bower pois separava as dependências. |
|
É como o @thulioph disse, a migração mais lógica seria entre npm -> Yarn(que com a atual versão do NPM, não deixa nada a dever para o Yarn). O bower possui um arquivo próprio para gerenciar, já que ele não usa o |
|
@WandersonAlves vc está corretíssimo, o wiredep é um plugin do Grunt. Ele injeta os assets do Porém, uma vez que estou removendo o Bower, não há mais o diretório O suporte ao NPM ainda é uma issue em aberto. |
|
Ah, entendi o X da questão agora kkkk Complicado :( |
|
Se fosse no webpack, dava para fazer um alias, não exist algo assim no grunt/gulp? |
|
@yanmagale acho que essa migração para o Yarn faz sentido. Se digitar hoje no seu terminal |
|
@icaioincau não quis seguir esse caminho porque minha intenção é eliminar o wiredep. Tudo o que li até o momento vai mais ou menos nesse sentido: https://stackoverflow.com/a/32572109 |
|
@adeonir algo no Yarn que vc não gostou? Sempre usei o NPM, mas me chamou a atenção a performance e no geral achei os comandos mais "semânticos". |
|
@felipepalazzo não é que não gostei, mas o Yarn faz o mesmo que o NPM, então acaba ficando redundante. |
|
@felipepalazzo esta issue ajuda ajuda? Replate Bower To Yarn |
|
vi que essa issue ainda está em aberto. aqui conseguimos com sucesso utilizar o Yarn para resolver as dependências. Usamos o gulp e tivemos que atualizar do V3 para V4 para o Glob seguir corretamente os symlinks gerados pelo Mas no fim do dia o build e serve estão funcionando corretamente com pacotes resolvidos pelo Yarn e empacotados com o wiredep. |
|
atualmente eu utilizo o Grunt juntamente com Bower, e desde alguns meses pra cá começamos a ter problemas instalando novos pacotes com o bower, até perceber que o Bower já não é mais uma boa escolha para gerenciar pacotes. Utilizando o bower-away eu consegui com sucesso criar meu package.json com os meus pacotes do bower e enviá-los pro folder node_modules/@bower_components O problema é que eu recebo um monte de erros ao tentar usar npm install, provavelmente porque alguns dos meus pacotes não conseguem ser encontrados pelo npm ou o versionamento deles entre bower e npm são diferentes. Sinceramente, eu não sou muito familiar com essas tecnologias e esta sendo uma dor de cabeça me livrar do bower que a solução no momento está sendo mantê-lo. Se algum tiver alguma dica ou solução e puder compartilhar. Versionar os pacotes na mão no package.json não é uma solução viável pra mim, já que meu projeto é muito complexo e há muitos pacotes . |
|
Npm não lida bem com o package que o bowe-away produz. Instale o yarn pelo Npm e use-o no lugar do npm pra instalar. Pode ser necessário talvez modificar o yarn-lock pq alguns plugin não tem suas versões corretas capturadas no lock. Veja minha resposta para um pouco mais de informação. |
|
Olá! Vale lembrar que a ideia do fork que fiz é para uma migração gradual, e não pretendo mantê-la. |
|
Alguém fez a migração com sucesso? O meu problema é o seguinte, no meu arquivo de configuração do Gulp está declarado os arquivos que devem ser concatenados para gerar o bundle, com base no wiredep, então o wiredep resolve todos os arquivos do bower e suas respectivas dependências, retorna eles e ainda concatena outros arquivos (que podem estar no bower, mas não foram resolvidos como o angular-i18n), e no fim ainda é adicionado os arquivos da minha aplicação. Quando eu removo o bower e o wiredep, eu tenho um problema nesse load. |
|
Ola @angeliski! |
Estou fazendo uma migração em passos usando o meu fork do wiredep (wiredep-away), que comentei acima. Depois de ter todas as dependências sendo resolvidas diretamente do Yarn, moverei o sistema de build do bundle de js para alguma coisa mais atual que tenha um melhor suporte que o gulp e suas extensões hoje (ex: Rollup, WebPack ou até mesmo browserify) PS: até o momento já migrei todas as dependências para o Yarn e ainda continuo injetando os scripts usando o meu fork do wiredep (que não é lá essas coisas mas quebrou meu galho). Migrar esses legados é problemático mesmo, mas pode ser muito recompensador. |
|
Opa @gchamon Eu quero me livrar do bower e do wiredep, mas eu comecei a ter problemas no wiredep mesmo. O que acontece é que hoje, o wiredep só é usado para resolver as dependências em si, depois o gulp gera um bundle enorme com todas essas dependências. Eu queria um caminho de migrar sem ter que colocar outro bundle (agora pelo menos), mas acho que vou ser obrigado a fazer isso né? :/ Aproveitando a deixa, o Srs. conhecem alguma ferramenta que permita testar isso? Ex. Eu tenho meus arquivos gerados com o gulp+bower+wiredep hoje, ai crio um teste que consigo rodar e validar que os arquivos são "identicos" quando tiver só o gulp+webpack? |
|
@angeliski Creio que não tem o pq fugir de um bundler, tendo em vista que bundles carregam mais rápido em conexões antigas (http 1.1), e acabam organizando melhor o seu código para entregá-lo em produção. O seu problema hoje (do meu ponto de vista) é que você está preso a forma como os arquivos do bower são importados para o seu projeto. Creio que seria mais sensato você usar um padrão mais modular usando o |
|
Caso vc use o gulp e não queira mudar muito a sua solução atual, podes usar o |
|
Sem dúvida @johnnyasantoss , meu problema maior é a maneira como os arquivos são importados. Eu queria fazer essa migração por um caminho menos custoso, porque o projeto para colocar webpack ainda está sendo estudado. Mas acho que vou "postergar" essa mudança para fazer junto da entrada do webpack no ecossistema. Muito obrigado pela força! |
|
@felipepalazzo, no fim, conseguiu resolver? |
Salve frontendrs ✌️
Contextualizando: tenho um SPA em Angular 1.x que usa Bower para gerenciar dependências e Grunt como task runner. Por tudo o que já foi comentado aqui, estou substituindo o Bower por Yarn.
Temos o wiredep pra injetar JS no
index.htmna ordem correta e vi que a comunidade recomenda, no caso de uma aplicação com Yarn/NPM, o uso do Browserify (ou Webpack) e, consequentemente, transformar tudo em modules.Na prática isso significa colocar
require()em todos os services, controllers, etc.Alguém já passou por essa migração? Alguma outra ideia e/ou sugestão para fazer essa migração de forma mais rápida? (infelizmente não consegui negociar muito tempo pra essa task )
The text was updated successfully, but these errors were encountered: