Assety z użyciem bower-rails i problem w testach

Potrzebna pomoc
1

Ostatnio zastanawiałem się, jak przechowywać assety w repozytorium, żeby Github nie wyświetlał, że projekt jest javascriptowy, gdy tak naprawdę jest to projekt w ror, z zamieszczonymi bibliotekami js. Postanowiłem wykorzystać bower (gemy z assetami nie istnieją do wszystkich bibliotek js a i tak jak ich się używa to uaktualniane są z opóźnieniem), a dokładnie bower-rails w ror. Nie jestem zwolennikiem node.js, ale w tym wypadku to rozwiązanie wydaje mi się mniejszym złem (jeżeli nie chce się przechowywać w repozytorium projektu).

wykorzystanie bower-rails w developie, działa bez problemu, chyba nawet nie trzeba zbyt dużo ustawiać (dodanie gema do Gemfile + initializer)

problem niestety pojawił się w testach i ładowaniu fontów z bootstrapa, czy font-awesome.

To teraz konkretniej:

  1. wykorzystanie bower-rails powoduje, że assety instalowane są przez bower do katalogu /vendor/assets/bower_components

  2. w application.css wystarczy że wpiszę require bootstrap

  3. w środowisku development, w kodzie źródłowym strony widzę coś takie:

dzięki temu jeśli w pliku bootstrap.css znajduje się url do czcionki

url('../fonts/glyphicons-halflings-regular.eot');

to czcionka ładowana jest bez problemu bo znajduje ją w ścieżce

/assets/bootstrap/fonts/glyphicons-halflings-regular.eot

  1. problem niestety pojawia się w środowisku testowym w testach integracyjnych, tam w kodzie strony mam linijkę

to niestety powoduje, że ścieżka dla czcionek wygląda tak:

/fonts/glyphicons-halflings-regular.eot

co jest oczywiście błędne i uniemożliwia uruchomienie serwera, spotkał się ktoś z takim problemem ?

2

Totalnie problem pierwszego świata. :wink:

Poza tym polecam http://rubygems.org/gems/bootstrap-sass oraz https://rails-assets.org.

3

nie rozumiem

czytasz wyrywkowo napisałem przecież, że “gemy z assetami (…) i tak jak ich się używa to uaktualniane są z opóźnieniem”

co do rails-assets to na początku byłem ich mocnym zwolennikiem ale jak kilka razy miałem sytuację, że ścieżko w tych ich gemach były złe i trzeba było zrobić kilka requir, żeby załadowało poprawnie wszystkie pliki z gema to darowałem sobie to rozwiązanie, bo nie jest doskonałe.

poza tym zastosowanie zamiennika to nie jest rozwiązanie, mi chodzi o rozwiązanie problemu z bowerem a nie wykorzystywanie innego rozwiązania, chyba że je odpowiednio umotywujesz, a nie podasz tylko link.

4

Nie wiem, który problem bardziej próbujesz rozwiązać - to, że Github kwalifikuje Twój projekt jako JS, a nie Ruby, czy problem z bibliotekami.

Dobre gemy aktualizowane są na bieżąco. Jeśli coś nie jest aktualizowane - fork (robiłem wielokrotnie, nie miałem z tym żadnych problemów).

Nie wiem, czy da się rozwiązać problem z bowerem i zasobami w plikach CSS jeśli chcesz wykorzytać też asset-pipeline. W dwóch projektach korzystaliśmy z bower-rails, ale było to tak źle zrobione, że ostatecznie skorzystaliśmy po prostu z bowera i pozbyliśmy się bower-rails.

5

to że github kwalifikuje projekt jako js to objaw, a problem jest związany z biblioteką.

“Dobre gemy” czyli nie wszystkie, a jak chcesz użyć coś niestandardowego to gema musisz samemu zrobić. Co do forków to oczywiście można wszystko forkować, ale forkowanie rodzi tylko kolejne problemy, np. z aktualizacją do nowszej wersji - trzeba zadbać o to, żeby samemu gem zaktualizować (tzn twój fork), poza tym - http://radarek.jogger.pl/2010/04/19/forkuj-z-glowa/ - coś w tym jest, nie jestem zwolennikiem forkowania wszystkiego “co po padnie”

W kilku małych aplikacjach (nie railsowych) użyłem bowera i działał bez problemu, zobaczyłem, że jest bower-rails to w aplikacji railsowej chciałem go wykorzystać, ale widzę, że nie jest idealny.

Jak nie widzisz rozwiązania problemu, to twoją odpowiedź już poznałem, a inne osoby ?

6

Zgłoś bug na githubie. To ich problem, nie Twój.

7

niby tak, ale jakby się głębiej zastanowić, to tworząc aplikacje desktopowe, nie przypominam sobie, żebym zewnętrzne biblioteki umieszczał w katalogu aplikacji, i stąd pomysł z bower, jak już pisałem gemy z assetami i rails-assets.org mają swoje wady, których w bower nie dostrzegałem do tego momentu. Jak z bower nic sie nie da zrobic w testach to bede musiał przerzucic sie na inne rozwiązanie

8

a mi się wydaje, że jednak dll czy jary się dorzucało do katalogu aplikacji.

9

znalazłem rozwiązanie tego problemu, ale przekopałem kilka issue na githubie i kod źródłowy bower-rails, ale dało się.

10

Poka poka!

1 Like
11

[quote=“filiptepper, post:10, topic:8486, full:true”]
Poka poka!
[/quote]Wiesz, skojarzyło mi się to z pika pika!, chociaż pokemonów, nie oglądałem i nie byłem ich zwolennikiem. Ale do rzeczy:

Pierwszym problemem w assetach posiadających plik bower.json (niestety nie wszystkie posiadają ten plik, w niektórych bibliotekach autor uznaje że plik bower.json jest mu zupełnie nie potrzebny) jest zawartość sekcji “main”. Oprę się na przykładzie bootstrapa i font awesome.

W bootstrapie sekcja main pliku bower.json wygląda tak:

  "main": [
    "less/bootstrap.less",
    "dist/css/bootstrap.css",
    "dist/js/bootstrap.js",
    "dist/fonts/glyphicons-halflings-regular.eot",
    "dist/fonts/glyphicons-halflings-regular.svg",
    "dist/fonts/glyphicons-halflings-regular.ttf",
    "dist/fonts/glyphicons-halflings-regular.woff"
  ],

a w font-awesome wygląda tak:

  "main": [
    "./css/font-awesome.css",
    "./fonts/*"
  ],

mimo że obydwie biblioteki mają swoje źródła css napisane w less to font-awesome nie ma informacji o tym w main, co powoduje, że do pliku less nie można się prosto odwołać.

A application.css wpisywałem wcześniej:

= require bootstrap
= require font-awesome

to powodowało, że prawdopodobnie bower automatycznie rozwijał path do pliku na podstawie tego co miał zapisane w sekcji main. I tak dla bootstrapa wybierał mi

less/bootstrap.less

a dla font-awesome wybierał mi

css/font-awesome.css

co już wprowadza niekonsekwencję, ale ona bazuje na tym co autor zechce lub nie zechce wpisać do bower.json, ale załóżmy na chwilę, że z tym możemy się pogodzić, w development fonty ładowane są prawidłowo bo ścieżka jest dłuższa, natomiast w środowisku testowym generowany jest jeden plik /assets/application.css i to powoduje, że path do fontów już jest nieprawidłowy, okazało się że bower-rails dostarcza rake task

rake bower:resolve # Resolve assets paths in bower components

który konwertuje pliki css do plików css.erb i wstawia odwołanie do asset_path tak, żeby font, obrazki, … działały w ror. Niestety zamiana plików css na css.erb powoduje, że proste odwołanie do assetów z bower już nie zadziała, bo plik

dist/css/bootstrap.css => dist/css/bootstrap.css.erb

./css/font-awesome.css => ./css/font-awesome.css.erb

więc w pliku application.css trzeba wpisać już konkretną ścieżkę do pliku erb

= require bootstrap/dist/css/bootstrap
= require font-awesome/css/font-awesome

Tylko podobno z tym jest jakiś problem przy prekompilacji assetów na produkcji (tego jeszcze nie sprawdzałem). Przypadek powyżej opisuje sytuację wykorzystania plików css, ale jak biblioteka ma pliki sass lub less to w tych plikach umieszczone są zmienne które pozwalają określić ścieżkę i wtedy nie trzeba już cudować z tym rake taskiem.

Z plikami less tak to rozwiązałem:

application.css

/*
 *= require vendor_less
 */

vendor_less.css

@import "bootstrap/less/bootstrap";
@icon-font-path: '/assets/bootstrap/dist/fonts/';

@import "font-awesome/less/font-awesome";
@fa-font-path: '/assets/font-awesome/fonts/';

Minusem tutaj jest konieczność podawania dłuższej ścieżki do pliku, ale jak na razie uważam, że jest to lepsze niż korzystanie z gemów assetowych, czy rails-assets. Może z biegiem czasu natknę się na problem z tym bowerem nie do przeskoczenia i wtedy zrewiduje swoje poglądy.

12

To daj znać czy Ci się uda to rozwiązać, bo u nas w developmencie i testach nie było problemów, ale deployment na Heroku okazał się być zbyt problematyczny i niestabilny.

Sorry, Pokemonów nie znam, za stary jestem.