Czy byłoby dobrą praktyką pozostawienie tylko bower.jsonpliku i gitignore całego bower_componentskatalogu?
Czy byłoby dobrą praktyką pozostawienie tylko bower.jsonpliku i gitignore całego bower_componentskatalogu?
Odpowiedzi:
Oficjalna strona Bower stwierdził:
UWAGA: Jeśli nie tworzysz pakietu, który ma być używany przez innych (np. Tworzysz aplikację internetową), zawsze powinieneś sprawdzać zainstalowane pakiety w kontroli źródła .
Koniecznie sprawdź link w wycenie, omawia on niektóre zalety i wady. Główną zaletą jest to, że ich sprawdzenie zapewnia, że zależności są zawsze dostępne, o ile jest dostępne repozytorium. Bez względu na to, co stanie się z Bower, GitHubem lub czymkolwiek innym byłoby potrzebne w innym przypadku.
.Gitignore plik w nowo wytworzonej Yeoman projektu angularjs ma bower_components (i) wymienione node_modules być ignorowane (jeśli nie wiesz Yeoman jest to bardzo renomowanych narzędzie internetowe rusztowanie dla nowoczesnych webapps, więc to wystarczająco dobre dla mnie!):
.gitignore
node_modules
dist
.tmp
.sass-cache
bower_components
Jest czas i miejsce na oba podejścia. W przypadku Yeoman warto polegać na bower.json, ponieważ jest to narzędzie w łańcuchu narzędzi i musi żyć i oddychać w ekosystemie altan. W przypadku wdrażalnej aplikacji internetowej ogólnie dobrą praktyką jest zatwierdzanie zależności i utrzymywanie większej kontroli.
Oto dobry artykuł, który mi się podoba, w którym to omówiono.
Yeoman generator wstępnie wypełnione .gitignore plik bower_components, ale także wstępnie wypełnione innych katalogów Myślę byłyby potrzebne do ostatecznej aplikacji (jak www), więc zrobiłem kilka badań.
Odkryłem, że www / index.html to zminimalizowana wersja pliku app / index.html. Katalog aplikacji i jego zawartość (w tym bower_components) zawiera pliki źródłowe potrzebne do katalogu wyjściowego (www). Zatwierdzasz katalogi źródłowe do kontroli źródła (np. Git), ale nie pliki generowane (np. Www). Menedżery pakietów, takie jak bower i npm, mają być używane podczas fazy kompilacji / generowania, a ich artefakty nie są przeznaczone do sprawdzania w kontroli źródła.
Ostatecznie źródło, które sprawdzasz w git, to absolutna minimalna konfiguracja potrzebna do zbudowania pozostałej części projektu do celów programistycznych lub wdrożeniowych.
Dobrze jest zignorować /bower_componentsdir i wpisać tylko bower.jsoni bower-locker.bower.jsonplik, jeśli tworzysz plik blokady za pomocą bower-locker napisanego przez Shawna Lonasa .
Przed utworzeniem altany-lockera istniała wada spowodowana problemem braku możliwości obkurczania altanki , ale można ją złagodzić dzięki powyższej bibliotece.
Uruchom następujące polecenia, aby to osiągnąć:
npm install bower-locker -g
lub
yarn global add bower-locker
następnie wygeneruj plik blokady na podstawie istniejącego bower.jsonpliku, uruchamiając:
bower-locker lock
Oryginalny bower.jsonplik zostanie zmieniony nabower-locker.bower.json
.gitignorepliku”