Ścieżki bloku-użytkowania-nie są zależne od pliku html?

Question

Mierząc wiele kłopotów, rozumiemy, jak traktowane są ścieżki w różnych punktach konfiguracji i użytkowania programu "grunt-usemin".

Mam następujący repo układ, gdzie korzeń repo będzie również korzeń Web App:

/dashboard/index.html 
/Gruntfile.js 
/vendor/...some 3rd party CSS and JS... 

Więc plik index.html -> somedomain.com/dashboard/index.html.

Plik index.html zawiera niektóre zasoby CSS i JS z folderu/vendor. Mam grunt skonfigurowane, aby umieścić zbudować wyjście w folderze produkcji:

/build/dashboard/index.html 

W pliku index.html, mam bloki usemin owinięty wokół całego łącza CSS i JS tagów skryptu:

<!-- build:css(.) app.min.css --> 
<!-- build:js(.) app.min.js --> 

I musiał podać "alternatywną ścieżkę wyszukiwania" z "(.)", aby tag skryptu "/vendor/backbone.js" znalazł go we właściwym miejscu. Do tego czasu szukałem/dashboard/vendor/backbone.js.

Chcę, aby dane wyjściowe przetwarzania zasobów CSS/JS były wyprowadzane do kompilacji/dashboard/app.min.css i kompilacji/dashboard/app.min.js, a zawarte przez index.html przy użyciu prostego względnego " app.min.css/js "ścieżka.

Problem polega na tym, grunt-usemin wydaje się być pomocą ścieżka Jestem podając dla obu kontekstach w sposób, który uniemożliwia im pracować razem „app.min *.”:

1) Traktuje ścieżkę jako relatywną względem katalogu kompilacji w celu utworzenia pliku; pliki kończą się w build/app.min.css i build/app.min.js.

2) Traktuje ścieżkę jako względną względem pliku index.html w celu wygenerowania nowych znaczników odnośnika/skryptu; przeglądarka ładuje program build/dashboard/index.html, który następnie próbuje załadować "app.min.css", który mapuje do kompilacji/dashboard/app.min.css.

Czy istnieje rozwiązanie?

Answer 1

Nie lubię go, ale to jedyny sposób znalazłem, aby to działało tak daleko jest aby podać pełną ścieżkę:

<!-- build:css(.) /dashboard/app.min.css --> 
<!-- build:js(.) /dashboard/app.min.js --> 

przewody do aplikacji pliki * Będąc w budowie// desce rozdzielczej obok index.html (czyli tam, gdzie chcę je), a index.html kończy się następującymi tagami:

<link rel="stylesheet" href="/dashboard/app.min.css"> 
<script src="/dashboard/app.min.js"></script> 

oznacza to, że aplikacja deska rozdzielcza jest teraz w pełni świadomi, że to miejsce w całości, więc nie możesz po prostu zmienić nazwy ani przenieść swojej pozycji w drzewie bez aktualizacji tych ścieżek.

Answer 2

Jestem naprawdę spóźniony na imprezę, ale byłem też bardzo sfrustrowany tym problemem i nie znalazłem satysfakcjonujących poprawek ani nie pracowałem. Więc opracowałem trochę brudnych sztuczek, aby mieć nadzieję, że lepiej poradzę sobie z tym problemem. Chciałbym się z wami tym podzielić.

Po pierwsze, szybko sprawdźmy, dlaczego tak się dzieje. Kiedy usemin generuje wyjściowe pliki JS/CSS, wykonuje proste połączenie ścieżek między katalogiem dest a katalogiem wyjściowym określonym w bloku usemin.Więc jeśli dest jest build i blok usemin jest

<!-- build:css(.) app.min.css --> 

następnie łączy build z app.min.css wypluć plik wyjściowy w build/app.min.css

Ale wtedy zadanie usemin prostu zastępuje ścieżkę w swoim bloku, aby skończyć z

<link rel="stylesheet" href="app.min.css"/> 

który jest teraz powiązanie złego katalogu od pliku HTML jest pod build/dashboard/index.html

Tak więc moja praca opiera się na tym pomyśle: co, jeśli katalog dest jest związany z miejscem, w którym znajduje się plik HTML? Czy to nie rozwiązałoby tego problemu? Więc biorąc pod uwagę powyższy przykład, co jeśli dest jest ? Widać, że wypluje lokalizację pliku wyjściowego i łączy ją poprawnie. Pamiętaj, że powinieneś utworzyć zadanie kopiowania do skopiowania na pliki HTML, więc upewnij się, że plik HTML jest kopiowany do build/dashboard/index.html, tak jak wcześniej.

Oczywiście następne pytanie brzmi: jeśli mam pliki HTML w wielu katalogach? Czy nie byłoby to zbyt bolesne i nieintuicyjne, aby utworzyć docelowy useminPrepare dla każdego katalogu, w którym mogą znajdować się pliki HTML? Dlatego właśnie tworzę bardzo specyficzne zadanie, aby poradzić sobie z tym problemem, podczas gdy ja tworzyłem własne rusztowanie. Nazywam to useminPreparePrepare Tak, jest to celowo nazywane głupim, ponieważ mam nadzieję, że pewnego dnia usuniemy tę rzecz, gdy ludzie useminu naprawią ten problem.

Jak sama nazwa wskazuje, jest to zadanie do przygotowania konfiguracji useminPrepare. Robi dokładnie to, co opisałem powyżej. Wszystkie konfiguracje lustra useminPrepare (w rzeczywistości większość z nich jest po prostu kopiowana do useminPrepare), z jednym wyjątkiem: musisz podać katalog src, aby zidentyfikować katalog główny wszystkich źródeł, aby mógł wygenerować względną ścieżkę do plików HTML. Więc w twoim przykładzie src: "." będzie dobrze. Aby użyć useminPreparePrepare, najpierw zaimportuj go do swojej kompilacji (możesz po prostu skopiować i wkleić mój kod, nie mam nic przeciwko), zmienić nazwę zadania useminPrepare na useminPreparePrepare i dodać właściwość src, o której właśnie wspomniałem. Upewnij się, że uruchamiasz useminPreparePrepare z dowolnym celem, który chcesz, a następnie natychmiast uruchom useminPrepare bez określania celu, aby uruchomić jego cele. Dzieje się tak dlatego, że useminPreparePrepare wygeneruje jeden cel dla każdego katalogu względem miejsca, w którym znaleziono pliki HTML, a kopie na twoich konfiguracjach dla celów useminPreparePrepare, które zostały uruchomione. W ten sposób twoja konfiguracja może po prostu wyszukać wszystkie pliki HTML.

Przykład

"useminPreparePrepare": { 
    // Search for HTML files under dashboard even though src is . 
    // because we want to avoid including files generated under build directory. 
    html: "dashboard/**/*.html", 
    options: { 
     src: ".", 
     dest: "build", 
     ... 

"usemin": { 
    html: ["build/**/*.html"], 
    ... 

"copy": { 
    html: { 
     files: [{ 
       expand: true, 
       src: ["dashboard/**/*.html"], 
       dest: "build" 
      } 
     ] 
    }, 
    ... 

Nadzieja to pomaga! Miłego dnia.

EDYCJA: Zdałem sobie sprawę, że biorąc pod uwagę powyższy przykład, jeśli faktycznie wszystkie pliki HTML są obecne w bieżącym katalogu, uwzględni się również wygenerowane pliki HTML, jeśli nie zostaną wyczyszczone przed czasem. Więc albo wyczyścisz je przed nimi albo zajrzysz pod katalog dashboard. Polecam oddzielić katalogi src i dest, aby konfiguracja wyglądała o wiele bardziej intuicyjnie.