LINUX.ORG.RU

А вот кому какой менеджер ассетов надо? Давайте обсудим

 ,


0

1

Я давно поддерживаю нодовский порт sprockets под названием mincer https://github.com/nodeca/mincer. И как-то он мне поднадоел :) . Хочется чего-то попроще и погибче.

- надоело тащить глобальные библиотеки через bower, хочется подо все npm.
- неудобно, что фактически приходится использовать 2 сборщика ассетов - один (кастомный), чтобы кнопелять компоненты проекта, другой (минсер) под раскладывание файлов на диске.
- возможно хочется переделать все на streams.
- когда в проектах очень много файлов - поиск притормаживает.
- нужно live update интегрировать.
- транспилеры под es6 тоже бы неплохо.

Вопрос к тем, кто развесистые клиентские яваскрипты собирает. А как у вас проекты организованы и чем вы пользуетесь? Особенно интересуют проекты, где все разбито на компоненты, и можно ли избежать ада, когда каждому компоненту нужно конфиг прописывать.

У меня как-то по наитию все сложено в древовидную структуру https://github.com/nodeca/nodeca.forum/tree/master/client. Но, честно говоря, не до конца понятно, как это дело гибко расширять. Например, добавив в некоторые компоненты riot.js или перекрыв скинами.

★★★★★

Пользую webpack, оба брата живы. Я не совсем фронтэндщик, впрочем.

  • Работает с npm, поддерживает bower
  • Раскладывай как угодно, просто пиши require (или import) для подключения. К наркомании вроде require(«index.scss») или require(«partial.html») быстро привыкаешь.
  • live update есть, но не позиционируется продакшн-фича
  • Умеет вообще всё, включая es6

Конфига 2 — devel и production, компонентам конфиги нафиг не нужны если не считать конфигом тот файл, где ты делаешь require всего.

x3al ★★★★★
()
Ответ на: комментарий от x3al

А как ему сказать, что какой-то yml содержит переводы, и надо разные языки по разным ассетам разложить? Или склепать большие бандлы, но под разные языки (чтобы меньше мелких файлов грузить)

Vit ★★★★★
() автор топика
Ответ на: комментарий от x3al

Я правильно понимаю, что от browserify оно отличается наличием небольшой магии, которая позволяет угадывать очевидные дефолты, но которой все равно не хватит для сложного проекта (и прийдется руками допиливать)?

Еще вопрос - а как оно хеши к именам файлов добавляет? И главное, как оно потом чинит, если какой-то скрипт тупо полезет к файлу по захардкоженному пути (или имени) без хеша?

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

И главное, как оно потом чинит, если какой-то скрипт тупо полезет к файлу по захардкоженному пути (или имени) без хеша?

Эмм. Оно смотрит на все require и все попытки include'ить любой ассет в любом поддерживаемом формате (а это js/coffeescript/typescipt/css/less/sass/на_что_хватит_фантазии, loader'ов в npm дофига). И далее либо загоняет в один файл, либо переписывает на нужный путь. Вполне типичный вариант — когда у тебя на выхлопе 1 bundle (можно разбить на chunk'и) с тем именем, что хочешь и внутри — вообще всё, включая CSS, иконки (png там или что — пофиг) и partial'ы.

Можно вытащить имя файла из выхлопа webpack-stats-plugin и вставить его в HTML если хочется. Всё.

x3al ★★★★★
()
Ответ на: комментарий от Vit

Оно как browserify, только менее наркомански имплементированное :)

Получить хеши бандлов можно, реврайтить html файлы, если ты не хочешь делать require('my.html') нужно будет руками/из gulp.

zz ★★★★
()
Ответ на: комментарий от x3al

Смотри, вот делаешь ты свой проект, с розовыми понями, все хорошо. И однажды надо подключить стороннюю библиотеку, написанную косорукими дебилами. И та библиотека говорит «дайте мне базовый URL, а дальше я сама буду подгружать переводы». А у тебя все ассеты давно с хешами в именах файлов, да и той папки вообще нет, потому что все в один бандл загнано. И как этой кривой либе файлы подкладывать?

Я без претензий, просто хочу понять, какие проблемы вебпак решать умеет, а какие нет. У меня создалось впечатление, что он расчитан на довольно простые случаи. И довольно «линеен» (все обычно зависит только от расширений, не от путей к файлам).

Vit ★★★★★
() автор топика
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от zz

А чем оно менее наркоманское? Меня browserify всегда подкупал тем, что можно как библиотеку дергать, и у каждого модуля можно в package.json особенности сборки прописать.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

«дайте мне базовый URL, а дальше я сама буду подгружать переводы»

Смотря как оно будет подгружать. Если через XHR — проще всего будет провести это мимо webpack'а. У меня сторонние библиотеки как правило не просят такого. Ближайшее извращение — jquery-timeago, но даже оно не пытается грузить само, поэтому там такой проблемы нет.

И да, как ты представляешь себе такой пакет в NPM?

x3al ★★★★★
()
Ответ на: комментарий от x3al

К популярным библиотекам, впрочем, есть специальные плагины webpack'а в том числе для подобных вещей.

x3al ★★★★★
()
Ответ на: комментарий от x3al

И да, как ты представляешь себе такой пакет в NPM?

Никак конечно :) . Я просто помню, с чем приходилось сталкиваться, и пытаюсь понять, как это в других вундервафлях сделано.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Я хз, я не настоящий фронтэндщик. В моих юзкейсах хватает для всего, хотя некоторые вещи кажутся странными.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Да не, с популярными проблем особо уже нет. Там давно обертки поправили.

Косяки у всякого редкого говна. Например у некоторых старых плагинов к knockout, которые пытаются сами лезть к глобальному объекту при регистрации.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Хз, как-то когда пользовался browserify все время какие-то не очевидные проблемы были, когда делаешь конфиг под что-то специфическое, а не копируешь бойлерплейты. С вебпаком раз в 10 меньше времени трачу на конфигурирование.

package.json

browser вебпак поддерживает, трансформации прописывать я не уверен что это хорошая идея - в npm должно все скомпиленное лежать уже.

Api не пользовал, но какое то есть.

zz ★★★★
()
Ответ на: комментарий от zz

Скомпилить не проблема. Но тогда будет отдельный файл для браузера, и модуль перестанет быть изоморфным (надо будет по разному подключать в зависимости от того где используется).

Я тоже помню времена, когда browserify был адски крив. Но вроде его уже пару лет как выпрямили.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Не, все будет так же - будешь звать require('module') и на клиенте и на сервере, нода это наоборот аргумент в пользу пре-компиляция, потому что она дофига отстает от бабела по es6 фичам.

Олсо, если у тебя разные сорсы для клиент/ноды, то пользуясь тем самым browser в package.json, можно иметь изоморфный модуль с не пересекающимися имплементациями, например https://github.com/matthew-andrews/isomorphic-fetch врапит сторонние модули для клиента и сервера в один.

Т.e. по части конечного результата с тз как ты пишешь код приложения, browserify и webpack это одна сотона.

Я тоже помню времена, когда browserify был адски крив. Но вроде его уже пару лет как выпрямили.

Вполне может быть.

zz ★★★★
()
Ответ на: комментарий от zz

Если ты про то, что вместо трансформов можно прописать оверрайд файла - это не принципиально. В любом случае, есть конфиг прямо в package.json, который объясняет browserify как правильно воткнуть модуль в проект. Я, собссна, об этом.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Да, я собственно о том же, что оверрайд файла поддерживается вебпаком :)

zz ★★★★
()

gulp + browserify. гибче, чем с webpack и никакой наркомании. однако кое что приходится ручками в гулп тасках написать, но оно и не проблема, даже наоборот, очень удобно.

staz
()
Ответ на: комментарий от Vit

Vit, это вполне реально сделать.

Тебе нужно будет заюзать file-loader для своих базово-уэрэльных файлов, и складывать их в папку (это задается параметром лоадера filename, например filename: '[path][name][ext]'). При подобной настройке файлы будут складываться согласно их расположению в src/ и никаких хешей добавляться не должно.

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

noomorph
()
Ответ на: комментарий от Vit

Я сам до сих пор ищу волшебную пулю для этого, но поделюсь с тобой своими результатами в этом направлении:

https://github.com/noomorph/quizzard/blob/master/src/containers/Amon-RU.js

Может быть, это натолкнет и тебя на какие-то полезные мысли.

noomorph
()
Последнее исправление: noomorph (всего исправлений: 1)

Для решения данной проблемы нужно:

- затранспилить live update через es7 компилеры

- притормозить поиск файлов когда их очень много.

- применить кюринг

- заассетить 3 компилера под сборку и закомпилять через ассесор яваскрипта

- затащить это все под npm и незаметно заасеертить и закюринговать

- начать изучать программирование

- попробовать понять, что такое проектирование

- изучить основы javascript

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.