webpack: 7 бед — один ответ

[xGromMx]

Простите, но плагин для bower вроде как не нужен, webpack умеет делать это из коробки github.com/xgrommx/angular-vk-app/blob/master/gulpfile.js#L40

[DenisIzmaylov]

Всё верно, я тоже использовал изначально встроенный ResolverPlugin, пока не столкнулся с проблемой.
Возьмём пример по этой ссылке:

...
            plugins: [
                new webpack.ResolverPlugin([
                    new webpack.ResolverPlugin.DirectoryDescriptionFilePlugin("bower.json", ["main"])
                ])
...

Как видим, этот плагин позволяет искать в директории запрошенного модуля файл bower.json и если он найден — возвращать файл, указанный в секции «main». Однако, я столкнулся с тем, что модуль bootstrap в своём описании содержит целую цепочку файлов (что логично):

...
  "main": [
    "less/bootstrap.less",
    "dist/css/bootstrap.css",
    "dist/fonts/glyphicons-halflings-regular.eot",
    "dist/fonts/glyphicons-halflings-regular.svg",
    "dist/fonts/glyphicons-halflings-regular.ttf",
    "dist/fonts/glyphicons-halflings-regular.woff",
    "dist/js/bootstrap.js"
  ],
...

Для того, чтобы подключить эти файлы и создан модуль BowerWebpackPlugin.

[clamaw]

browserify беднее по функциональности и рантайм у него сильно больше. Подмену модулей, кажется, можно осуществить loader'ами.

[vmakhaev]

Недавно перешел с browserify на webpack. Hot module replacement очень радует. В остальном, в моём случае, разницы особо нету. А, ну еще, gulp выпилился за ненадобностью.

Посмотрел на webpack как раз после доклада moscowjs.

[vintage]

Есть несколько моментов, которые меня сильно смущают:
1. entry-point почему-то является одним файлом. Причём, на сколько я понял, js-файлом. Хотелось бы указывать папку.
2. Если я подключаю скрипт из модуля, то ожидаю, что подключится и css и прочие файлы. Но на сколько я понял, каждый файл должен быть достижим через ссылки из других фалов. Это ворох копипасты.
3. К js безусловно добавляется webpack бутстрап, даже если он там не нужен (не используется require, например).

Буду рад, если скажете, что я ошибаюсь по всем трём пунктам :-)

[kossnocorp]

1. Это с одной стороны непривычно и кажется глупым, особенно для пользователей concat решений (например Sprockets). Но на деле вы явно строите дерево зависимостей начиная от вершины-entry и это очень упрощяет работу с большими проектами а так же ускоряет вход новых людей тк всегда и без проблем можно понять как работает приложение. Но если вам нужно просто взять и включить содержимое определенной папки — webpack это позволяет с помощью контекстов.

2. Это очень просто реализуется с помощью webpack, можете посмотреть как мы это решили для своего проекта: component-resolver-webpack & component-css-loader.

3. Бутстрап webpack — необходимое зло, но зло небольшое:

243b + 20b per module + 4b per dependency

Источник

Важно понимать что это не просто concat утилита, а очень мощный менеджер зависимостей который многие вещи делает проще, но тем не менее требует инвестиций. Если вы не знаете зачем вам модульность, то вполне вероятно вам и не нужен webpack.

[vintage]

1. Что мешает директории быть этой самой вершиной entry? Или, на худой конец, какому-нибудь ini-файлу? И вообще, я хочу иметь возможность любой модуль со всеми его файлами оформить в виде независимой библиотеки. То есть чтобы подключились все файлы модуля и все необходимые им зависимости.

require("./template/" + name + ".jade");

Это какая-то чёрная магия. Я хочу простую вещь — чтобы модуль подключался целиком или же не подключался вовсе. Без шаманств.

2. Довольно костыльное решение

component-css-loader modifies original component source code and adds require('component_name.styl') at the first line.

Бывает много скриптов и мало стилей или много стилей но мало скриптов или и стилей и скриптов мало, зато много шаблонов. Привязка к именам файлов ни к чему хорошему в этих случаях не приведёт.

3. От чего же необходимое? Если используются рантайм фичи вебпака — безусловно. Но если не используются — зачем их пихать? На мой взгляд стоит разделить проект на:
а) собственно сборщик, который собирает исходники
б) рантайм библиотека, как один из исходников, которая подключается как и все остальные исходники — по наличию зависимости.

И да, я знаю зачем мне модули

[DenisIzmaylov]

1. Да, без проблем. Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать? Действительно логичней и чище было бы декомпозировать, исходя из того, что есть модуль, в котором указаны его основные зависимости. У тех в свою очередь могут быть другие. Например:

var componentTemplate = require('./component.jade');
require('./component.css');
module.exports = contentTemplate;

.my-custom-component {
  background: url(./bg.png');
}

— в этом случае webpack подключит шаблон, CSS и фоновое изображение. При этом вы можете спокойно и без проблем создавать документацию, разные сценарии сборки, тестирования и пр.

Другой вариант — использовать подход для подключения bower-модулей, изложенный в статье. Он без проблем подключит bower.json с таким фрагментом (реальный пример из жизни — компонент ladda-bootstrap):

...
    "main": [
        "dist/ladda-themeless.css",
        "dist/ladda.js"
    ],
...

Тут важно осознавать, что модуль должен вернуть что-то — объект или функцию. В случае со списком выше — тут просто. А вот если вы подключите по вашему примеру заведомо неизвестный набор jade-шаблонов, как вы с ними будете работать? В случае с webpack — один шаблон = одна функция:

var messageTemplate = require('./template/message.jade');
$('#messages').append(messageTemplate({userName: 'vintage', ...});

2. Во многом ответил в предыдущем пункте. Согласен про то, что если есть проект, в котором для модулей много CSS-файлов, то будет затратно их подключать по отдельности — тут можно либо собрать всё предварительно через gulp/grunt, либо написать плагин по образу и подобию:
github.com/lpiepiora/bower-webpack-plugin
И всё сообщество будет вам благодарно! С webpack вообще всё возможно. Он разве что кофе не готовит.

3. Require.js так и был устроен — там это вынужденная необходимость, ведь сборщик немаленький. Но в случае с webpack, как kossnocorp, речь идёт о 243 байтах — мы на HTTP-запрос к отдельному загрузчику можем больше потерять.

[vintage]

Когда я смотрел его пол года назад он добавлял куда больше 243 байт мусора. Думаю мне стоит сделать второй подход к с наряду. Может удастся допилить до юзабельного состояния.

> Но если в директорию вы решите поместить readme-файл? А если тесты для него? Как это исключать?

Очень просто — правильно именуя файлы. Например:
request.env=node.js — реализация для ноды
request.env=web.js — реализация для браузера
request.stage=test.js — универсальные тесты

[DenisIzmaylov]

Опять же, имеется ввиду сборка для продакшн = после минимизации.
«Правильно» — это очень относительно, у каждого ведь своё «правильно». У меня оно немного другое. Не лучше, не хуже — просто другое. Поэтому тут было бы удобней сделать плагином, они как раз для таких случаев предназначены. Это действительно просто.

[sompylasar]

webpack и кофе готовит :) github.com/webpack/coffee-loader

[DenisIzmaylov]

Здесь был комментарий, который я перенёс выше. Не нашёл кнопки удаления.