Skip to content

Latest commit

 

History

History
executable file
·
44 lines (33 loc) · 8.05 KB

faq.md

File metadata and controls

executable file
·
44 lines (33 loc) · 8.05 KB

English description | Описание на русском

FAQ

По всем вопросам можно обращаться в gitter или по почте [email protected].

  1. У меня webpack и NPM-scripts, я не понимаю, зачем нужен TARS с Gulp? Для всего есть свой инструмент. Естественно, можно извернуться и для всех своих задач использовать только NPM-scripts. Но Gulp — это не только таск-менеджер (что уже делает его на одну ступень выше по удобству, чем NPM-скрипты), но и возможность легко переносить файлы в поток. С NPM-скриптами уже не так просто сделать правильную параллельную обработку задач. В любом случае потребуется еще некий index.js, в котором будет отдельно реализован последовательный flow выполнения тасков и параллельный. Также, не забываем, что и асинхронные задачи бывают. Насчет именно webpack: инструмент был создан для того, чтобы разрешать зависимости в JavaScript изначально. Сейчас его обвесили еще плагинами, но его главная задача так и осталась прежней. Отсюда следует, что Gulp + webpack = любовь, они не конкуренты друг другу. Можно почитать комментарии на эту тему в документации к webpack + Gulp.

  2. Почему именно Gulp, а не Grunt? Gulp это потоковый сборщик проектов на JavaScript. Он использует Streams и действительно является очень быстрым. Для примера у меня есть проект, где около тысячи stylus файлов, Grunt'у нужно примерно 2.5 секунды на сборку и 2 секунды на обработку autoprefixer'ом. Gulp все это делает за 0.5 секунды выигрывая у Grunt минимум в 4 раза.

  3. Как лучше построить процесс разработки с помощью TARS? Единого ответа тут нет. Все зависит от специфики разработки. Рассмотрим несколько типов проектов.

    • Долгоиграющий и единственный. В этом случае все просто. Создавайте компоненты, страницы, храните все в какой-либо CVS — в общем, этот сценарий самый скучный.
    • Много проектов с повторяющейся функциональностью. В этом случае есть несколько путей работы с TARS:
      • создать библиотеку переиспользуемых блоков и включить ее сразу в собственный форк TARS. Таким образом, при ините нового проекта в нем сразу будут все нужные блоки;
      • использовать git или любую другую CVS. Пусть заиниченный TARS находится в git, а каждый новый проект — отдельная ветка;
      • хранить библиотеку повторяющихся блоков отдельно.
    • Много разных проектов. Также весьма простой сценарий, при котором каждый проект может быть отдельным репозиторием в git (или другой CVS).

Указанные способы выше — не догма, а лишь пример, как получить больше пользы от TARS.

  1. У нас в команде есть свой сборщик на Gulp/Grunt, хотелось бы использовать наработки из него в TARS. Можете перенести необходимые таски в user-tasks. Для использования grunt-тасков, если не хотите переписывать на Gulp, есть пакет gulp-grunt, который запускает grunt-таск в Gulp. Но все же рекомендуем портировать grunt-таск в Gulp. Тем более, все плагины для Grunt доступны в Gulp. Если необходимо, чтобы проект инитился всегда с этими дополнительными тасками, то рекомендуем создать форк TARS, добавить в нем необходимые изменения, инитить проект, с указанием ссылки на ваш форк. При этом, для упрощения обновления форка, все кастомные таски следует складывать в users-tasks, а зависимости для этих тасков указывать в user-package.json. Они будут ставиться с каждым заиниченым проектом.

  2. У меня OS X (Ubuntu, Linux Mint ...) В готовую сборку попадают не все файлы проекта. Нужно увеличить ulimit в tars-config.js

  3. Я ничего не понимаю в Gulp, могу ли я комфортно пользоваться данным сборщиком? Знания работы с Gulp не обязательны. На данный момент сборщик покрывает большинство задач frontend'а. Все, что нужно знать — описано в документации.

  4. Мне кажется, что используется слишком сложная файловая структура. Могу ли я ее модифицировать так, как нужно мне? Если вы умеете работать с Gulp, то после переименования/удаления/создания папок, необходимо править соответсвующие таски или создавать user-tasks. Некоторые каталоги не обязательны и могут быть спокойно удалены. Также можно спокойно расширять файловую структуру для JavaScript с использованием опции в конфиге сборщика. Для основной папки со статикой и папки с картинками можно задать имя в опциях в конфиге сборщика.

  5. Вроде бы все поставилось, но ничего не работает. Что делать? У меня Windows (7, 8, 10) Скорее всего не все зависимости поставились. Запустите команду NPM i еще раз. Если в результате выполнения данной команды есть ошибки, то большая просьба прислать их на почту ([email protected]) или в gitter.