Блог

Я читал документацию Rails webpacker gem, где говорится:

Webpacker упрощает использование предварительного процессора JavaScript и пакета webpack 4.x.x для управления JavaScript, подобным приложениям, в Rails. Он сосуществует с конвейером ресурсов, поскольку основной целью webpack является JavaScript, подобный приложению, а не изображения, CSS или даже фрагменты JavaScript (все это продолжает существовать в app / assets).

Однако Webpacker можно использовать и для ресурсов CSS, изображений и шрифтов, и в этом случае вам может даже не понадобиться конвейер ресурсов. Это в основном актуально при использовании исключительно фреймворков JavaScript на основе компонентов.

Я пытаюсь понять обоснование использования обоих старых конвейеров ресурсов для CSS / изображений / JS-sprinkles, если webpacker способен обрабатывать все это?

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

Это просто для поддержки устаревших приложений, и в конечном итоге конвейер старых ресурсов исчезнет, а webpacker будет использоваться для всего в приложениях Rails?

Как сопровождающий приложения, которое существовало до Webpacker, я могу привести вам одну причину:

Сложно перенести существующий интерфейс из Sprockets в Webpack.

Sprockets собирает все JS в один большой файл с общей областью видимости. Webpack изолирует область действия каждого модуля JS. Чтобы перейти на Webpack, вам нужно убедиться, что ваш код все еще работает с изоляцией области видимости.

Что часто является проблематичным, потому что во времена Sprockets у вас также не было надлежащих требований JS, и вам приходилось полагаться на глобальные или переменные верхнего уровня для обмена кодом и данными между вашими исходными файлами JS.

Rails не предлагает безболезненный путь перехода от компиляции Sprockets к Webpack. Итак, он должен поддерживать оба.

Но чтобы ответить на ваш другой вопрос — в дальнейшем вам следует использовать Webpacker, если у вас достаточно JS, чтобы сделать его стоящим.

Если ваш интерфейс прост, вы избежите некоторых неудобств JS, если будете использовать Sprockets. Например, если вы хотите добавить 10 строк JS в свое приложение, вы можете не захотеть настраивать всю среду JS с управлением зависимостями и node_modules etc — это цена использования Webpack / Webpacker. Было бы еще более бессмысленно управлять средой JS, если все, что вы хотите, это скомпилировать CSS и добавить дайджесты к именам файлов ваших изображений — на что Sprockets вполне способен, без package.json и всего остального, связанного с JS.

Следовательно, есть вторая причина:

Webpacker хорош для приложений, которые имеют значительную кодовую базу интерфейса. Sprockets хорош для добавления немного JavaScript в традиционное приложение, отображаемое на сервере, и для приложений, в которых JavaScript вообще отсутствует.