Пути блоков grunt-usemin не относятся к html-файлу?

Имея много проблем, понять, как обрабатываются пути в различных точках конфигурации и использования grunt-usemin.

У меня есть следующий макет репо, где корень репо также будет корнем веб-приложения:

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

Итак, файл index.html -> somedomain.com/dashboard/index.html.

Файл index.html включает некоторые ресурсы CSS и JS из папки /vendor. Я настроил grunt для помещения вывода сборки в папку сборки:

/build/dashboard/index.html

В файле index.html у меня есть блоки usemin, обернутые вокруг всех ссылок CSS и тегов сценария JS:

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

Мне пришлось указать «альтернативный путь поиска» с помощью «(.)», чтобы тег скрипта для «/vendor/backbone.js» нашел его в нужном месте. Пока я этого не сделал, он искал /dashboard/vendor/backbone.js.

Я хочу, чтобы результат обработки ресурсов CSS/JS выводился в build/dashboard/app.min.css и build/dashboard/app.min.js и включался в index.html с использованием простого относительного «app.min. путь css/js".

Проблема в том, что grunt-usemin, похоже, использует путь «app.min.*», который я указываю для обоих контекстов, таким образом, что они не могут работать вместе:

1) Он рассматривает путь относительно каталога сборки для целей создания файла; файлы попадают в build/app.min.css и build/app.min.js.

2) Он рассматривает путь как относительный к файлу index.html для целей создания новых тегов ссылки/скрипта; браузер загружает build/dashboard/index.html, который затем пытается загрузить «app.min.css», который сопоставляется с build/dashboard/app.min.css.

Есть ли решение?


person odigity    schedule 25.09.2013    source источник


Ответы (2)


Я действительно опоздал на вечеринку, но я также был очень разочарован этой проблемой и не нашел удовлетворительных исправлений или обходных путей. Поэтому я разработал несколько довольно грязных трюков, чтобы, надеюсь, лучше обойти эту проблему. Так что я хотел бы поделиться им с вами.

Прежде всего, давайте быстро рассмотрим, почему возникает эта проблема. Когда usemin создает выходные файлы JS/CSS, он выполняет простое соединение пути между вашим каталогом dest и выходным каталогом, который вы указали в своем блоке usemin. Итак, если dest равно build, а блок usemin равен

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

затем он объединяет build с app.min.css, чтобы выдать выходной файл в build/app.min.css

Но тогда задача usemin просто заменяет путь в вашем блоке, чтобы вы в итоге получили

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

который теперь связывает неправильный каталог, так как ваш файл HTML находится под build/dashboard/index.html

Итак, моя работа вращается вокруг этой идеи: что, если каталог dest находится относительно того, где находится файл HTML? Разве это не решит эту проблему? Итак, учитывая приведенный выше пример, что, если dest равно build/dashboard? Вы можете видеть, что он выдаст местоположение выходного файла и правильно свяжет его. Имейте в виду, что вы должны создать задачу копирования для копирования ваших HTML-файлов, поэтому убедитесь, что ваш HTML-файл скопирован в build/dashboard/index.html, как и раньше.

Конечно, следующим вопросом будет: что, если у меня есть HTML-файлы в нескольких каталогах? Не будет ли очень болезненным и неинтуитивным создание цели useminPrepare для каждого каталога, где могут находиться HTML-файлы? Вот почему я создаю особую задачу для ворчания только для того, чтобы обойти эту проблему, пока я создавал свои собственные леса для ворчания. Я называю это useminPreparePrepare Да , это намеренно названо глупо, потому что я надеюсь полностью удалить эту штуку однажды, когда люди-использователи действительно исправят эту проблему.

Как следует из названия, это задача по подготовке конфигов useminPrepare. Он делает именно то, что я описал выше. Все его конфиги отражают конфиги useminPrepare (на самом деле, большинство из них просто копируются в useminPrepare), за одним исключением: вам нужно указать каталог src, чтобы определить корневой каталог всех ваших источников, чтобы он мог генерировать относительный путь. в файлы HTML. Так что в вашем примере src: "." будет нормально. Чтобы использовать useminPreparePrepare, сначала импортируйте его в свою сборку (вы можете просто скопировать и вставить мой код, я не возражаю), переименуйте задачу useminPrepare в useminPreparePrepare и добавьте свойство src, о котором я только что упоминал. Убедитесь, что вы запускаете useminPreparePrepare с любой целью, которая вам нравится, а затем немедленно запускаете useminPrepare без указания цели, чтобы были запущены все ее цели. Это связано с тем, что useminPreparePrepare создаст одну цель для каждого каталога относительно того, где находятся HTML-файлы, и скопирует ваши конфигурации для цели useminPreparePrepare, которую вы запустили. Таким образом, ваша конфигурация может просто искать все файлы HTML.

Пример

"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"
            }
        ]
    },
    ...

Надеюсь это поможет! Хорошего дня.

РЕДАКТИРОВАТЬ: я понял, что, учитывая приведенный выше пример, если вы фактически включите все файлы HTML из текущего каталога, вы также включите сгенерированные файлы HTML, если они не будут очищены заранее. Поэтому либо вы очищаете их перед ними, либо смотрите в каталоге dashboard. Я бы порекомендовал разделить каталоги src и dest, чтобы конфигурация выглядела более интуитивно понятно.

person initialxy    schedule 08.02.2014

Мне это не нравится, но единственный способ заставить его работать — указать полный путь:

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

Это приводит к тому, что файлы приложения* находятся в /build/dashboard вместе с index.html (именно там я их и хочу), а index.html завершается следующими тегами:

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

Это означает, что приложение информационной панели теперь точно знает о своем местоположении в целом, поэтому вы не можете просто переименовать или переместить его положение в дереве без обновления этих путей.

person odigity    schedule 25.09.2013