Из формулировки вопроса, скорее всего, не совсем понятно, о чём речь, поэтому поясню на более человеческом языке.
У меня есть мини-проект, в рамках которого делается обёртка над видео-плеером, предоставляющая наружу удобный интерфейс для настройки плеера. Обёртка написана на ES6 использует пару вспомогательных функций, импортируемых из рядом лежащих файлов. Также в пакете лежит 2 scss-файла, которые в конечном счёте переводятся в css (оформление для плеера). В результате сборки у меня должна быть папка dist, содержащая минифицированный js и 2 css'а. Сценариев использования 2:
- прямое подключение файлов (js, css) на странице сайта и inline-инициализация плеера;
- подключение минифицированного файла как внешнего пакета в рамках другой сборки и использование его интерфейса.
И вот тут я задаюсь вопросом: чем лучше всё это собирать?
Пока не появилось необходимости подключать всё это как пакет, для сборки использовался grunt и все были счастливы. Но ни пляски с бубном, ни заклятия не помогли при попытке затащить этот пакет с помощью webpack'а в основной проект: класс обёртки упорно не виден. (На стороне grunt'а используется babel+browserify, при подключении минифицированного js'а напрямую на странице всё хорошо.)
Удалось собрать силами того же webpack'а с указанием в output параметра library. В итоге сборка хорошо работает и при прямом подключении на странице, и в виде пакета. Но сильно смущает одно обстоятельство: для того, чтобы сгенерить css-файлы, пришлось прописать для них отдельные entry, и на каждый css-файл создаётся свой js-файл (разумеется, формальный, потому что исходного js'а для него нет). Жить они мне не мешают, но глядя на них я понимаю, что что-то делаю неправильно. Можно, конечно, собирать css отдельной командой, или удалять лишний js после сборки. Но, возможно, есть более правильное решение.
Собственно, хочется спросить совета у знающих людей -- как бы вы решали эту задачу?
Средний
Простой
Простой
Средний
