Ótimo artigo! Parabéns!

Valeu! ;)

Front-ender com medo de terminal está começando a sofrer cada vez mais. O grupo Grunt, Yeoman e Bower é só um dos exemplos de como o terminal ainda é e provavelmente será por bastante tempo, um ótimo lugar e intuitivo local para trabalhar. A galera do vim agora mal sai de lá haha

Verdade. Aprender a usar o terminal virou quase obrigação.

Você poderia colocar aqui no rodapé do link sua apresentação do Speakerdeck sobre o Bower que há comentários lá que podem agregar ainda mais o conteúdo. ;)

Belo artigo Nando.

Muito bom o post! Parabéns!

Nando, parabéns pelo artigo, muito esclarecedor! :)

No caso do jQuery, ao inserir "//= require jquery", ele continua ativando o do Rails. Como fazer para o ele utilizar o do Bower?

Você precisa remover a gem jquery-rails do Gemfile. Se você está usando alguma funcionalidade do Rails que precisa de JavaScript (remote form, por exemplo), instale o pacote jquery-ujs com o Bower: bower install jquery-ujs.

Obrigado, agora parece óbvio, rs! Valeu pela força.

Tranquilo! Foi bom porque aproveitei e atualizei o post com essas infos. ;)

Nando, você recomenda fazer o checkin dos componentes do bower?
Ou adicionar o "vendor/assets/bower" ao gitignore e usar um hook pra executar o bower antes do assets:precompile, por exemplo?

Eu estou fazendo o commit dos componentes. Gosto da ideia de isto acelerar o processo de deploy.

Olá Nando, excelente artigo!

Concordo com você que não faz sentido agregar dependências client-side diretamente no Gemfile, mas vi que você só citou libs JS, isso também funciona pra adicionar dependências como o bootstrap ou foundation por exemplo?

Funciona sim. Eu, por exemplo, uso um pacote chamado normalize-scss para normalizar o CSS no Sass. O Bootstrap também rola. Já o Foundation não tem o bower.json no repositório, mas alguém já criou.

$ bower search foundation
Search results:
    foundation git://github.com/zurb/foundation
    foundation-icons git://github.com/zurb/foundation-icons.git
    components-foundation git://github.com/components/foundation.git
    bower-foundation-css git://github.com/ch1c0t/bower-foundation-css.git
    sass-foundation git://github.com/mmcgahan/sass-foundation.git
    bower-foundation-datepicker git://github.com/edgarnadal/bower-foundation-datepicker.git
    backbone.foundation.reveal.modal git://github.com/shaohua/backbone.foundation.reveal.modal

Nando... excelente post cara.

Funcionou tudo perfeitamente na asset pipeline do rails 4.

Parabéns e obrigado.

Valeu! ;)

Ótimo artigo Nando!

Você conseguiu usar o jquery-ujs sem ter que passar o caminho até o arquivo rails.js?
Pelo que vi não existe o arquivo bower.json, então o que fiz foi instalar desse repositório pra funcionar: https://github.com/fullscre...

Pois é, Marcelo. Eu tive que deixar assim:

//= require jquery-ujs/src/rails.js

Nando, boa noite,

Em meu testes usando Bower com Rails 4, no application.js tive que usar o caminho completo do arquivo, por exemplo, utilizo um JS chamado pusher, a instalação dele ficou em um caminho assim:
vendor/assets/bower/pusher e dentro o arquivo puser.js ficou na pasta dist/pusher.js
e no meu application.js tive que fazer //= require pusher/dist/pusher pois //= require pusher como vc mostrou no exemplo não rolou, sabe se preciso de alguma configuração para que ele entenda que deve varrer o arquivo em qualquer pasta a baixo de vendor/assets/bower ?

Tudo depende do pacote. O Sprockets utiliza a chave "main" para saber qual o arquivo que precisa ser carregado, o que no pacote do Pusher não existe. Por isso você precisa passar o caminho completo.

Esse pacote é extremamente zuado, diga-se de passagem. Ele não especifica quais arquivos devem ser adicionados e traz o repositório completo. :/

Minha sugestão é que você faça o fork do projeto e corrija essas questões. ;)

Oi Nando!

Em developmet na asset pipeline do rails 4 está rodando tudo certinho. É uma maravilha. O meu Gemfile está limpinho. Não tem nada de front-end lá.

O problema está em production, onde é preciso compilar a asset e coisas como fontes e imagens acabam não caindo nos lugares corretos.

Por exemplo, eu estou tentando usar o font awesome. Em development tudo fica bonitinho, mas em production os ícones simplesmente desaparecem.

O motivo para tal é que as fontes são jogadas na pasta public/assets/ e o font awesome originalmente espera em public/assets/fonts.

Antes do bower eu pegava esses código, modificava, versionava no meu git e pronto.

Entendo que com o bower não parece fazer sentido nem mesmo versionar estes fontes.

Como você lida com questões semelhantes a esta?

Muito obrigado.

Tudo o que está dentro do diretório app/assets já é adicionado ao load path do Sprockets por padrão. Dito isso, toda vez que você executa rake assets:precompile seus arquivos serão copiados automaticamente para dentro do diretório public/assets. O próximo passo é referenciar a fonte que você quer usar no CSS com o helper font-url.

Agora, eu preciso saber como esse font awesome organiza tudo isso, porque o correto é ter uma versão específica para sass/rails, o que não sei se acontece no momento.

Eis aí o ponto onde eu queria chegar.

O vendor em geral declara a asset dele da maneira que for mais conveniente pra ele. Por exemplo, o twitter bootstrap e o font awesome esperam que as fontes estejam dentro da pasta "../fonts".

(mestre... não brigue comigo por citar o bootstrap... hehehe)

Só que na asset esses arquivos irão parar em "./" após compilados.

O que eu fazia antes do bower era ficar ajustando os arquivos dos caras para usarem os helpers do sprockets - algo como url-path("blablabla"), por exemplo.

No meu entendimento isso é uma coisa ruim pelos seguintes aspectos:

1. Sempre que eu atualizar estas dependências de terceiros, eu vou ter que refazer este trabalho.

2. Isso me força também a ter a minha própria versão da lib que eu estou usando.

Na minha opinião de leigo, para a integração do bower com a asset pipeline ficar supimpa, teria que existir mais um tipo de arquivo manifesto onde eu informaria a origem das fontes, ícones, imagens ou outras coisas desse gênero, e o diretório onde isso iria parar dentro da compilação final da asset.

Por exemplo:

O trecho abaixo é do font awesome:

@font-face {
font-family: 'FontAwesome';
src: url('../font/fontawesome-webfont.eot?v=3.2.1');
src: url('../font/fontawesome-webfont.eot?#iefix&v=3.2.1') format('embedded-opentype'), url('../font/fontawesome-webfont.woff?v=3.2.1') format('woff'), url('../font/fontawesome-webfont.ttf?v=3.2.1') format('truetype'), url('../font/fontawesome-webfont.svg#fontawesomeregular?v=3.2.1') format('svg');
}

Mas ao compilar a asset os arquivos fontawesome-webfont serão jogados para a pasta ./ ao invés de ./fonts.

Seria show se pudesse ter algo assim:

fontawesome-webfont.eot, compile_saving_at: "/assets/fonts"

Assim você não precisaria ficar ajustando os arquivo originais. O que você precisaria fazer seria apenas ensinar ao sprockets onde ele deve jogar alguns arquivos especiais de terceiros.

Consegui me fazer entender? hehehe.

Um abraço mestre.

Mestre... pensa só se o asset:precompile pudesse ler a seguinte configuração:

config.asset.copy
.from("font-awesome/font/fontawesome-webfont.eot")
.to("font/fontawesome-webfont.eot")

E a compilação criasse:

public/assets/fonts/fontawesome-webfont.eot

Isso eliminaria qualquer necessidade de ficar enjambrando os arquivos originais dos vendors.

Duvido que o pessoal do Sprockets adicionaria algo assim. De qualquer modo, experimenta abrir uma issue sugerindo, para ver o que eles dizem.

A questão, na verdade, é que o Rails exige situações especiais. Nenhuma biblioteca deve ser obrigada a suportar o Rails e, por este motivo, acredito que os usuários Rails desses pacotes é que devem se preocupar em fazer com que isso funcione.

Minha sugestão é que você faça um fork do projeto (font awesome) e adicione um arquivo bower.json que ignora tudo que não seja arquivos LESS, Sass, CSS e fontes. Depois, você pode criar um arquivo manifesto no diretório scss que carrega as dependências para o Rails (uma cópia do arquivo fontawesome.scss, mas que carrega um arquivo "_path.scss" específico para o Rails, usando o helper font-url).

Entendo Nando.. .a minha ótica sobre o problema é o seguinte:

a. Não tem jeito de mudarmos o comportamento do sprockets, pois ele também não é obrigado a suportar todo mundo. O "default" dele é que tudo fique na raiz ou então você usar os helpers url-* dele. Vejo que isso só é viável quando o código é de minha propriedade.

b. Não tem jeito de mudarmos os vendors, pois eles podem (e tem todo o direito) de fazer o que quiser com o código deles.

c. Não acho certo ficar customizando os vendors, pois seria uma dor de cabeça se manter up-to-date.

Será que a alternativa não seria criar um plug-in pra asset ou até mesmo uma tarefa grunt pra resolver o problema? Algo que lesse um arquivo de tradução e amarrasse essas pontas?

Será que eu estou enxergando o problema de uma forma muito distorcida? Ou as coisas que eu relatei até agora fazem sentido?

Desculpe escrever tanto, mas o assunto parece bem pertinente.

Muito obrigado.

Mestre...

Acabei resolvendo o problema, mas obviamente de uma maneira que não me orgulha.

Eu abri uma pasta no public chamada font. Copiei pra lá os arquivos de font necessários. O servidor web os serviu estaticamente e deu tudo certo.

Obviamente fiquei sem o recurso de fingerprint da asset, mas acho que por enquanto isso não vai me ferrar.

Torço para que no futuro haja uma solução mais elegante.

Um abraço.

@fnando, no artigo você fala:

Note que você não precisa passar exatamente o arquivo que quer carregar; o jQuery, por exemplo, é instalado em `vendor/assets/bower/jquery/jquery.js`.
O Sprockets reconhece o arquivo bower.json e carrega a dependência corretamente através da chave main.
Caso esta chave não tenha sido definida, ele tenta carregar um arquivo com o mesmo nome do diretório.

Estou com uma app rails que tem dentro um app escrito em um Framework JavaScript. Estamos querendo separar isso e ai colocamos o bower para gerenciar o zilhão de dependências javascript, porém esse reconhecimento do bower.json das libs não vem sendo reconhecida. Por exemplo no jquery-ujs eu teria de carregar assim:

//= require "jquery-ujs/src/rails"

Ou seja esse reconhecimendto de `bower.json` ou `component.json` que eu achei que ocorreria não ocorre, ou deve necessitar de alguma configuração a mais que não estou sabendo qual é. Isso que estou falando em um APP rails 3.2.16. Muito provavelmente eu estou fazendo algo erra e que eu não detecto pois pelo que vejo aqui nos comentários é que a galaera tem conseguido de forma geral usar bem essa sua dica. Mas ao que vejo não parece que o sprockets tenha essa integração de reconhecer o arquivo bower.json

[EDIT #1]:
Apenas uma observação, vejo que realmente o Sprockets tem ai a sua integração para ler o arquivo bower.json como em sprockets/lib/sprockets/base.rb:133, porém muitos pacotes baixados via `bower install` como o do `jquery` por exemplo em vez de `bower.json` usam `package.json` acredito que devido ao NPM, temos até um texto em http://goo.gl/ehrYMo falando sobre o uso de bower.json e package.json, porém mesmo assim o pacote `jquery_ujs` baixado com o bower vem com o bower.json e mesmo assim apresenta o erro de integração com o erro de load.

De fato, no Rails 3 o Sprockets não reconhece a opção main. Só consegui fazer funcionar deste modo:

//= require jquery/jquery
//= require jquery-ujs/src/rails

Se você olhar o mesmo arquivo na versão 2.2.2 do Sprockets (versão usada em um app que gerei do Rails 3.2.16), verá que não existe suporte para o Bower.

Fora que nem todo projeto bower usa a nomeclatura bower.json alguns usam module.json, component.json ou notação node que é package.json

Bem como não consegui uma solução estou usando um paliativo com

"jquery-ujs":       "https://github.com/paulopatto/jquery-ujs.git"

e chamando assim:

//= require "jquery-ujs/jquery-ujs"

Aproveitei o embalo e atualizei o artigo com essa informação para o Rails 3. ;)

Nando, estou tendo problemas para utilizar o compass. Confesso que é o primeiro projeto onde deixei de utilizar o Gemfile para gerenciar pacotes ou libs que trabalham com o front. Porém, no caso do compass, nem no Gemfile o rapaz funciona. Poderia verificar o que posso estar faz? Como estou utilizando o twitter bootstrap, utilizando o bower search encontrei pacotes do tipo "compass-twitter-bootstrap", mas já tenho o bootstrap adicionado. Como posso fazer para utilizar o twitter bootstrap e o compass de forma separada? (estou organizando as libs front em vendor/assets/components)

Tive problemas com proxy na hora de usar o Bower mesmo o npm estando configurado para a função.
A solução foi um export no terminal

export HTTPS_PROXY=http://ip:porta

E após isso instalou o pacote normalmente.

Obrigado pelo post, muito bom. Simples e direto!
bower init em 5 4 3 2 1

Parabéns, me ajudou a entender melhor as vantagens de usar Bower nos meus novos projetos

Muito foda... tô usando o bower em um novo projeto e me ajudou bastante! Obrigado!

Valeu! ;)

Olá Nando, ótimo artigo!

Porém estou com uma dúvida.

No meu bower.json tenho o modernizr como dependência, e o .bowerrc apontando para "vendor/assets/bower".

Na minha aplicação vou chamar o application.js com o require dos pacotes antes de fechar a tag body, mas preciso chamar somente o modernizr no head. Como posso fazer isso?

<%= javascript_include_tag 'modernizr' %>

(404) http://localhost:3000/javascripts/modernizr.js

Teria uma forma para isso?

Abraço.

Muit bom o post. Ficou muito melhor a separação. Parabéns!

Uma dúvida, em muitos pacotes o Bower baixa um arquivos desnecessários para redistribuição, exemplo, no caso do jQuery ele baixa duas pastas: src (com todos os componentes do jQuery em separado) e dist (com os arquivos jquery.js e jquery.mim.js). No caso para publicar em produção minha app, os arquivos da pasta src são desnecessários. Tem alguma maineira de fazer com que Bower retorne apenas os arquivos redistribuíveis?

Obrigado!

Muito bom! Obrigado pela base Nando Vieira!

Valeu, é uma boa base! Parabéns!

Muito bom esse artigo!