Ще більше комфорту в розробці фронтенда з TARS

TARS

Пройшли чергові півроку з останніх новин про TARS раз і два), а отже, настав час поділитися новинками. Як завжди нагадаю, що TARS — це заснований на Gulp складальник фронтенда, який допомагає фронтенд-розробнику або навіть цілої команди створювати проекти будь-якої складності. Ми продовжуємо впевнений хід по Росії і не тільки. TARS вже використовують в Нідерландах, Японії, Китаї, Україні, Польщі та інших країнах. Це можна помітити і за кількістю зірок на github, і за кількістю учасників чату gitterі за кількістю установок TARS-CLI за останній місяць (більше тисячі, а в піку більше 3 тисяч). Ми закрили майже дві сотні issue, випустили два великих оновлень. Користувачі складальника активно репортят, беруть участь у розробці. Можна сказати, що у нас народилося маленьке співтовариство.

Основні зміни
TARS став по-справжньому, без будь-яких застережень, модульним. Швидкість запуску і складання збільшилася в рази. До найбільш значимих змін відносяться webpack і автооновлення проекту (оновлення версії складальника, а не перезавантаження в браузері).

Нарешті JavaScript можна збирати не тільки простий конкатенацией файлів. Навіть соромно було, що в 2016 році збірка скриптів в TARS була настільки відсталою. Webpack розв'язав руки в роботі з JavaScript. Hot Module Replacement, який також підтримується в TARS з коробки, творить чудеса. А з опцією injectChanges для стилів в Browser-sync розробка стає просто фантастичною — браузер не перезавантажується, а на льоту застосовує зміни в CSS і, якщо це можливо, в JavaScript. Якщо піти далі, то можна перекласти роботу зі стилями та шаблонами на webpack. Так як будь таск в TARS тепер можна без праці перевизначити — перенесення відповідальності за CSS і шаблонизацию легко реалізувати з webpack. Якщо ж говорити тільки про складання JavaScript, то webpack тут надає масу можливостей, про які простіше прочитати в документації. Крім того, з другої версії (вона знаходиться в стадії beta-тестування) з'явився Tree shaking, який дозволяє імпортувати в кожну точку програми тільки той код, який реально використовується в модулі.

З приходом webpack в проект ви можете запитати, навіщо взагалі Gulp потрібен, якщо все можна зробити за допомогою webpack і npm-скриптів? Відповідь тут дуже проста: з Gulp все набагато простіше.

Насправді, про webpack питання не стоїть — у TARS можна просто відключити таски, які займаються компіляцією шаблонів і складанням CSS і використовувати відповідні лоадери. Так що варто перефразувати питання по-іншому: навіщо потрібна якась абстракція у вигляді Gulp, коли його функції можуть виконувати npm-скрипти?
Вже написано багато статей, в яких пояснюється вся міць і перевага npm. Постараюся відповісти на найбільш вагомі аргументи. Думаю, відразу варто уточнити, що мова йде про тому випадку, коли у нас багато завдань, між якими є залежності в черговості виконання.

Почнемо з того, що вам доведеться писати свою реалізацію для запуску задач послідовно і паралельно. Навіщо, якщо є Gulp, який вміє це робити на «відмінно»? До того ж іноді зручно працювати з потоками при обробці якогось набору файлів. Або вам доведеться писати таку функціональність самому, або просто відмовитися від неї.

Серйозний аргумент на користь переходу на npm-скрипти — погана підтримка плагінів для Gulp. Мова йде про gulp-плагінах, які є обгорткою для різних модулів типу UglifyJS, PostCSS і т. д. Природно, може бути невеликий «лаг» між, наприклад, оновленням UglifyJS і gulp-uglify, але найчастіше це не суттєво. Часто буває так, що творець Gulp-плагіна та самого пакету, для якого цей плагін був написаний, — одна особа. Не виключається і той факт, що хтось може просто закинути свою розробку. У цьому випадку можна або продовжити розробку за автора, або використовувати пакет безпосередньо, без gulp-обгортки. Таким чином працює webpack в TARS.

Ну, і наостанок: робота з тасками куди більш приємна, ніж довгі онучі в package.json. Звичайно, для проекту, в якому всього кілька завдань, онуча навряд чи вийде. У випадку з TARS, коли ми намагаємося покрити якомога більше потреб розробника одним інструментом і маємо складні залежності між послідовним і паралельним виконанням тасков, використання npm-скриптів не виправдовує себе, а, швидше, вставляє палки в колеса.

Gulp — це дуже проста у використанні штука, протестована в різних оточеннях, на різних платформах. Для вас є всього 4 методу API і можливість створення складного сценарію паралельного і послідовного запуску тасков. Зрештою, вам навіть не потрібно знати, що під капотом знаходиться саме Gulp, адже TARS просто працює.

Якщо підтримка webpack вже давно реалізована в багатьох проектах (а де-то складальник побудований тільки на webpack), то такої штуки, як автооновлення проекту, не надає ніхто. З TARS ви можете спокійно розробляти ваш сайт/сервіс/що-то ще й отримувати всі останні фічі TARS однією командою. При цьому всі налаштування, файли проекту, користувальницькі таски і вотчери будуть збережені. Ще вчора ви конкатенировали JavaScript-файли, а вже сьогодні, оновивши проект, отримали можливість використовувати webpack. Всі кроки оновлення логируются плюс є можливість додати свої команди, які будуть запущені при оновленні проекту.

Далі підуть не настільки значущі, але не менш корисні зміни.

Корисні дрібниці
ESLint замінив JSCS і JSHint. До речі, зовсім недавно майнтейнер проекту JSCS Марат Дулін повідомив про перехід команди JSCS в проект ESLint. Так що, якщо ви ще не використовуєте ESLint, — саме час почати. Перевірка коду стала проходити набагато швидше, з конфіг працювати зручно — в загальному, зручність зі всіх сторін.

Код TARS і TARS-CLI гарненько отрефакторили і переписали на ES6 (з підтримкою тих функцій, що доступні в 4 версії NodeJS). В цілому все стало чистіше і зрозуміліше, сподіваємося, що pull request'ів у зв'язку з цим стане більше. Основний gulpfile тепер радує око, тому що складається всього з 30 рядків. Так як код написаний на ES6, довелося відмовитися від підтримки NodeJS версії не нижче 4. Документацію привели в актуальний стан, виправили багато друкарських помилок, помилок і т. д.

Додали можливість використовувати SVG-символи. При цьому є можливість вибрати варіант підключення готового спрайту символів: вставити код спрайту в тіло кожної сторінки, тримати всі символи в окремому файлі, а при підключенні вказувати шлях до цього файлу (природно, автоматично) або дати можливість вам самому реалізувати підвантаження файлу з символами.

Модулі були перейменовані в компоненти. При цьому ім'я папки з компонентами/модулями можна налаштувати в конфіги, якщо нову назву вам не по душі. З'явилася можливість вкладати компоненти компоненти. Ця фіча також підтримується з боку CLI-утиліти.

Було багато прохань про те, щоб можна було створювати компоненти з кастомних структурою з допомогою CLI. Ви просили — ми зробили! Тепер можна описати схему компонента в json-файлі, при цьому схем можна зробити скільки завгодно.

Майже всі плагіни, які використовуються в TARS можна налаштувати так, як зручно вам в одному загальному конфігураційному файлі.

Реалізували можливість компіляції стилів автоматичної конкатенацией, а з допомогою точок входу, в які ви можете імпортувати тільки те, що потрібно в кінцевої збірки. Сподіваємося, що це дасть більше свободи у роботі зі стилями.

Значно прискорили перезбирання Jade-шаблонів. Кешуємо тепер все, що можна і пересобираем тільки те, що дійсно необхідно на даному етапі.

А найголовніше — всі ці нововведення ви можете отримати просто запустивши команду:
tars update-project

Ваш проект буде автоматично оновлено до останньої версії з збереженням всіх налаштувань.

Плани на майбутнє
Розробка TARS не зупиняється, є ще багато того, що хотілося б реалізувати:
  • нарешті вже перейти на 4 версію Gulp, коли вона вийде з beta-тестування;
  • перейти на другу версію webpack, коли він вийде з beta-тестування;
  • дати можливість використовувати [Rollup](https://github.com/rollup/rollup) в якості збирача JavaScript;
  • створити інфраструктуру для TARS-плагінів. Система плагінів — різні доповнення до TARS, які потрібні, щоб вирішувати «вузькі» завдання. Найпростіший приклад — таски для верстки листів. Уявіть, ви просто набираєте «tars install tars-email» — і ваш локальний TARS завантажуються таски для комфортної роботи з версткою електронних листів;
  • реалізувати можливість використання PostCSS без будь-яких препроцесорів;
  • реалізувати підтримку css-модулів;
  • нарешті закінчити промо-сайт;
  • написати більше тестів на TARS і TARS-CLI.
Зараз TARS розвивається без втрати сумісності з попередніми версіями, з-за чого в нових версіях залишаються сутності, від яких було б непогано позбавитися. Хочеться зламати цю сумісність, щоб у наступній версії не залишилося нічого зайвого. Обов'язково реалізуємо механізм хоча б напівавтоматичного оновлення з 1.x.x до 2.x.x.

За подальшими планами слідкуйте на github. Там же можна вплинути на проект. Ми завжди раді новим ідеям. Пишіть gitter і на пошту tars.builder@gmail.com найближчим часом, можливо, з'явиться канал в Slack та/або Telegram.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.