Określanie lokalizacji .bowerrc podczas wywoływania instalacji altanki

Question

Mam projekt nadrzędny, który zawiera moduł potomny. Moduł ma swój własny bower.json, który określa zależności modułów i .bowerrc, który określa, do którego folderu mają zostać pobrane. Te zależności są połączone w module HTML.

Projekt macierzysty używa package.json do zarządzania zależnościami węzłów.

Aby uniemożliwić użytkownikom konieczności uruchamiania zarówno npm install (dla zależnościami dominująca) i cd module, bower install, cd ../ (dla zależnościami Module), dodałem postinstall skrypt do package.json:

"scripts": { 
    "postinstall" : "./node_modules/.bin/bower install ./module/ --config.directory=\"./module/public/bower_components\"" 
} 

pamiętać, że Jedynym sposobem, w jaki mogłem przekonać Bower'a do zainstalowania zależności modułu w /module/public/bower_components było jawne podanie directory w skrypcie postinstall.

Jednak ta informacja zawiera już ./module/.bowerrc, więc najlepiej "zdać sobie z tego sprawę". Ułatwiłoby to również konserwację urządzenia package.json i zapewniało większą mobilność.

Próbowałem zostały również przeniesienie zależność Bower i postinstall skrypt do mojego modułu package.json, używając haka postinstall w macierzystej package.json uruchomić npm install w katalogu modułu. Ale to podejście kończy się w module. zależności pobierane do folderu rodzica node_modules.

Czy istnieje lepszy sposób rozwiązania tego problemu?

Answer 1

Konfiguracja Bower używa następującej kolejności priorytetów do rozwiązywania konfiguracji dla kompilacji.

Od docs Bower na http://bower.io/docs/config/

• argumenty CLI poprzez --config
• zmiennych Środowisko
• Local .bowerrc znajdujących się w bieżącym katalogu roboczym
• Wszystkie pliki .bowerrc górę drzewa katalogów
• . Plik bowerrc znajduje się w folderze domowym użytkownika (~)
• . Plik bodrc znajduje się n w folderze globalnym (/)

W twoim przypadku możesz umieścić plik .bowerrc w tym samym folderze co pakiet package.json, ale skonfiguruj wszystkie właściwości z prefixem modułowym/publicznym, aby uruchomić swoją instalację.

Podoba mi się twój pomysł zarządzania wszystkimi zależnościami z jednego miejsca w package.json.