mrsum 31 авг 2015 в 14:29

Webpack для Single Page App

6 мин

74K

HTML*JavaScript*Node.JS*Веб-разработка*

+13

Комментарии 61

Delphinum 31 авг 2015 в 14:34

Как то начал его пользовать, но закончил тем, что не смог решить на нем одну простую задачу, а именно:
необходимо было разделить весь JS на несколько файлов так, чтобы основная логика была в одном файле, а несколько придаточных логик в других. При этом в зависимости от разрешений текущего пользователя, файлы нескольких придаточных логик загружать не должны были (ну или вместо них должны были загружаться заглушки).

Может здесь подскажут, как это реализуется?

mrsum 31 авг 2015 в 14:42

Да конечно, это реализуется очень просто. Для этого Вам необходимо в файл конфигурации добавить еще один entrypoint. Рассмотрим ситуацию, когда есть скрипты основного приложения и скрипт формы авторизации:

entry: {
  auth: _path + '/app/auth.js',
  app: _path + '/app/index.js',
  vendors: dependencies
},
new HtmlPlugin({
  title: 'App',
  chunks: ['app', 'vendors'],
  filename: 'index.html',
  template: 'app/index.html'
}),
new HtmlPlugin({
  title: 'Auth',
  chunks: ['auth', 'vendors'],
  filename: 'auth.html',
  template: 'app/auth.html'
}),

Вот и вся магия.

Delphinum 31 авг 2015 в 14:52

А как решается, когда подключать придаточную логику, а когда заглушку?

mrsum 31 авг 2015 в 15:18

Подразумевается что вызов require() в каждом entry point — подтянет только ту логику, которая будет там использована.
Отвечая на Ваш вопрос – самостоятельно =)

Delphinum 31 авг 2015 в 15:26

Так задача не в том, подтягивать ли логику или не подтягивать в зависимости от необходимости. Ограничения такие: если заходит пользователь с currentUser.role != 'admin', то ему загружается в качестве модуля 'admin' файл 'public/js/mock/admin.js', а если пользователь с currentUser.role == 'admin', то ему загружается файл 'public/js/admin.js'. Более того, если пользователь не является админом и попробует открывать все файлы js, которые найдет, он не должен найти адрес файла 'public/js/admin.js'. То есть для «не админа» в результирующем js файле (файлах) не должно быть ссылок на 'public/js/admin.js'.

mrsum 31 авг 2015 в 16:13

Если не секрет, почему Вы эту логику не хотите реализовать через ACL?

Delphinum 31 авг 2015 в 18:02

Так речь об обычном web-сайте. Вы предлагаете прикрутить ACL к nginx?

dizel3d 14 ноя 2016 в 16:13

Это решается с помощью CommonsChunkPlugin. Вот пример.

dizel3d 14 ноя 2016 в 17:38

Поясню свой пример. Вы хотите, чтобы X использовал либо A, либо B. А я предлагаю инверсию зависимостей: A и B конфигурируют X. По сути получаете тот же результат: подключаете скрипт X и либо A, либо B.

geakstr 31 авг 2015 в 15:21

del

cyber_ua 31 авг 2015 в 15:19

А как вы решаете проблему с круговыми зависимостями?

mrsum 31 авг 2015 в 16:15

Мне кажется или это проблема архитектуры конкретного приложения?

DmitryOlkhovoi 31 авг 2015 в 16:49

Циклическими*
Нет, это не проблема приложения, просто такое бывает необходимо :))

Я вижу сотни любителей вебпака, но ни один мне не может ответим, чем же этот толстый вебпак, лучше, удобней того же require.js, который поддерживает все тоже самое, и даже больше. Хоть не из коробки

Delphinum 31 авг 2015 в 18:04

Так require.js и webpack это два совершенно разных инструмента. Второй умеет собирать проект в статичный файл, оптимизировать его, добавлять хэши и тому подобное. Webpack лучше уж сравнивать с Grunt, чем с requireJS.

DmitryOlkhovoi 31 авг 2015 в 18:21

require так же умеет собирать, в том числе и html.

requirejs.org/docs/optimization.html.

Grunt'ом можно рулить вебпакт, но не сравнивать :)

Delphinum 31 авг 2015 в 18:22

Так это же просто оптимизация, а для сборки может потребоваться еще много чего, разве нет?

DmitryOlkhovoi 31 авг 2015 в 18:25

Прочитайте цели, который там написаны. Прежде чем задавать еще один вопрос :))

RequireJS has an optimization tool that does the following
Combines related scripts together into build layers and minifies them via UglifyJS (the default) or Closure Compiler (an option when using Java).
Optimizes CSS by inlining CSS files referenced by import and removing comments.

Так же повторюсь html и все, что вам угодно. При этом с require можно не билдить в дев окружении

Delphinum 31 авг 2015 в 18:32

Возможно я плохо задал вопрос и вы таки меня тыкните носом, чему я буду очень признателен, но где предварительная компиляция Sass, CoffeeScript, добавление хэшей к измененным файла, дробление на куски и подобный функционал, необходимый любому инструменту сборки? В целях, которые там написаны, я вижу только оптимизацию JS и CSS.

DmitryOlkhovoi 31 авг 2015 в 18:39

Хм, вебпак так же использует сторонние модули для работы с такими вещами?
В данном случае я отдаю такое напрямую в траспилиры и пре(пост)процессоры. С помощью таск ранера, например gulp или grunt. Собственно и сам require оптимизатор запускается галпом.
На этом моменте можно начать сравнивать у кого конфиг меньше и что более популярно :))
webpack — 7к звезд, галп — 15к

Delphinum 31 авг 2015 в 18:57

Хм, вебпак так же использует сторонние модули для работы с такими вещами?

В том то и разница, что Webpack — это инструмент, который объединяет несколько инструментов в один конвеер, который после выполняется над проектом и мы получаем результирующие js'ы, css'ы и html'ы. Он под это заточен, как и Grunt. С другой стороны, RequireJS это больше инструмент для подключения модулей. Ему даже не обязательно уметь оптимизировать и склеивать JS файлы (я считаю это лишним функционалом).

В данном случае я отдаю такое напрямую в траспилиры и пре(пост)процессоры. С помощью таск ранера, например gulp или grunt.

Я тоже (пользую Grunt), но вопрос не в этом. Не совсем верно сравнивать системы сборки проекта (таск ранеры, как вы их называете) и RequireJS, который по сути является инструментом загрузки зависимостей.

DmitryOlkhovoi 31 авг 2015 в 19:05

Во, гору спасибок вам, так понятней) Теперь можно холиварить webpack vs gulp плагинами :)

Ему даже не обязательно уметь оптимизировать и склеивать JS файлы (я считаю это лишним функционалом).

Ну тут как и browserify, ему нужен свой механик, что бы собрать все + html темлпейты в стиле AMD модулей, тоже я пока негде не видел)

Delphinum 31 авг 2015 в 19:15

Теперь можно холиварить webpack vs gulp плагинами :)

Да что тут холиварить. Хотите программируемые инструменты, пользуйте Gulp, хотите непрограммируемые, пользуйте Webpack.

vladsharikov 19 дек 2016 в 04:31

Актуализирую инфу по звёздам :)
webpack 22
gulp 25

PS webpack догоняет, причём нереально уверенно (особенно учитывая время создания одного и другого инструмента)

stas404 19 дек 2016 в 11:26

На днях вышел RC, а через пару недель обещают webpack 2 final зарелизить — догонит и перегонит.
Там и документация наконец в порядок приведена, и сам инструмент плюшками оброс.

vladsharikov 7 июл 2017 в 10:53

Актуализирую инфу :) webpack: 29.7, gulp 26.7. обогнал.

stas404 уже 3 вышел =)

arusakov 31 авг 2015 в 18:10

Есть хорошая страничка со сравнением разных сборщиков webpack.github.io/docs/comparison.html

GrizliK1988 31 авг 2015 в 18:15

В том и дело, что не из коробки. Будучи абсолютным мастером в обращении с require.js нет необходимости использовать webpack. Но вся штука как раз в том, что вебпак не требует большого количества времени на изучение/кофигурирование. Сам недавно перевел ~500 js файлов на webpack.

Циклические зависимости так же вполне можно решить.

Delphinum 31 авг 2015 в 18:21

Эмм… А что нужно такого знать про require.js? Элементарный инструмент ведь.

mrsum 31 авг 2015 в 18:26

Webpack это:
– СommonJs
– компонентность
– быстрая скорость сборки
– 100% доставка компонентов системы по первому вызову
– Пре- и пост- процессоры
– Минификация
– Сборка *.map файлов
– Хеширование конечных файлов
– и еще десятки пунктов…

Из коробки. Вот чем webpack хорош

DmitryOlkhovoi 31 авг 2015 в 18:30

Абсолютно тоже самое из коробки делает и умеет require.js. Увы месье — не удивили :)
Так же CommonJs Modules, а то не понятно, что вы ввиду имеете. Стандарт сверверного js или стиль подключения модулей.

dfuse 29 сен 2015 в 08:09

RequireJS не умеет подключать файлы без явного указания плагина (css!./path/to.css).
RequireJS не умеет без диких плясок с бубном работать с TypeScript/ES6/Coffee/JADE/SASS, ему надо либо прекомпиляци, либо опять же плагины, а в вебпаке это делается за минуту.

Я создал две одинаковых системы для дичайше огромного сайта и пришел к выводу, что Webpack удобнее, т.к. позволяет на клиенте видеть и при разработке и после билда максимально идентичное окружение. Кол-во багов, которое вылезало из-за разницы в работе на живую и после сборки, было немного удручающим…

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

gbezyuk 31 авг 2015 в 18:44

А hot reloading require.js умеет?

DmitryOlkhovoi 31 авг 2015 в 18:50

То есть подключив левый плагин, в терминах webpack — модуль, настроив hot релоад уже означает, что я точно так же не могу подключить его к галпу? Или об этом в туториалах не пишут? :)

gbezyuk 31 авг 2015 в 19:16

я просто спросил. webpack это умеет из коробки dev-server'ом, и этим активно пользуется, например, Dan Abramov в своём redux-devtools.

Eternalko 31 авг 2015 в 23:32

Webpack решает их так же как и node.js

cyber_ua 1 сен 2015 в 00:17

Можно пример?
Например, у меня есть файл
a.js

module.exports = {
    x: require( "./x" ),
    b: require( "./b" )
};

x.js

var z = require( "./z" ) ; 
//...

z.js
var  b = require( "./a" ).b
//...

я знаю что на прямую могу подключить b, но можно ли как то решить такую ситуацию не меняя код?

Eternalko 1 сен 2015 в 11:51

Вопроса не понял. А в чем проблема? Вы пробовали это запустить?

Если коротко, то я не вижу тут проблем. Если у вас логические зависимости — исполнение кода одного модуля зависит от исполнения кода другого модуля и обратно, то у вас есть 2 выбора:

— Поменять структуру
— Использовать паттерн Message Broker.

Советую второе.

Eternalko 31 авг 2015 в 23:31

В любом месте:

if (userAccess) {
  require.ensure(['secret', 'superpupersecret'], function (require){
    var supersecret = require('secret');
    supersecret.launchNuke();
  }); 
else {
  alert('you shall not pass');
}

cyber_ua 1 сен 2015 в 00:19

Насчет ensure, как для ensure указать ссылку на cdn ??
Я пробывал просто вставить

 require.ensure(['https://ajax.googleapis.com/ajax/libs/angularjs/1.3.15/angular.min.js', 'superpupersecret'], function (require){
    var supersecret = require('secret');
    supersecret.launchNuke();
  });

Eternalko 1 сен 2015 в 11:43

А вы чего ожидаете? Что он соберет chunk во время компиляции или в во время рантайма только вещи из URL будет скачивать?

Правильное решение такого рода проблем:

npm install angular --save

cyber_ua 2 сен 2015 в 11:19

Я хочу динамически подключать скрипт если нужно, ensure и так подключает скрипт динамически, интересно можно ли подключить скрипт по ссылке например.

mrsombre 2 фев 2016 в 14:51

Webpack не подключает внешние ресурсы, используйте например script.js

var $s = require("scriptjs");
$s("url", function (){
 // using script
})

cyber_ua 2 сен 2015 в 11:20

del

Delphinum 1 сен 2015 в 01:15

А заглушку то как подгрузить и скрыть адрес «secret» файла в путях?

Eternalko 1 сен 2015 в 11:40

Не понял вопроса.

Delphinum 1 сен 2015 в 13:00

Я объясню задачу еще раз и постараюсь более точно.

Предположим у нас есть кучка JS файлов, которые после сборки превращатся в 'core.js' файл. В этом файле активно используется модуль 'admin' (файл 'admin.js'). Используется этот модуль как и положено, через объявление зависимостей. Файл это ('admin.js') так же собирается из некоторой кучки файлов.

Для обеспечение безопасности, определены следующие два ограничения:
1. Если пользователь, который посетил страницу, не является админом, ему под модулем 'admin' должен загружаться модуль заглушка (он в файле 'mock/admin.js')
2. Если пользователь, который посетил страницу, не является админом, открыв файлы 'core.js' через браузер (исходники), или файл 'mock/admin.js', он не должен найти в этих файлах каких либо ссылок или чего либо, что позволило бы ему найти файл 'admin.js' и посмотреть его исходники

Eternalko 1 сен 2015 в 13:36

Если валидация происходит на стороне JS то это невозможно сделать. В теории.
Вы прячете URL в стоге сена. А у меня есть большой магнит.

Разве сервер может шаманить и раздавать разный файл в зависимости от сессии.

Если это просто Security through obscurity то пройдитесь обсфукатором и делов то.

Delphinum 1 сен 2015 в 13:40

Если валидация происходит на стороне JS то это невозможно сделать.

На стороне сервера тоже можно, это не принципиально. Проблема в том, что webpack не может сложить проект так, чтобы в нем не осталось ссылок на подключаемые модули (либо я не понял, как это сделать).

Kongo 1 сен 2015 в 15:42

Это выглядит как задача, которую webpack решать не призван. Он отделил модуль, который используется только в определенных сценариях (admin.js), а вот ограничить доступ к нему можно с помощью других инструментов. Например, используя сервер приложения и x-accel-redirect для nginx.

Delphinum 1 сен 2015 в 16:48

Это выглядит как задача, которую webpack решать не призван.

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

а вот ограничить доступ к нему можно с помощью других инструментов

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

Kongo 1 сен 2015 в 17:41

Динамическое ограничение доступа к файлам не выглядит как задача для системы сборки (webpack только частный случай), на мой взгляд.
Подмена файла больше похожа на магию, чем использование рассчитанных на это инструментов. Впрочем, как её предлагается устроить? Я предлагал делать проверку статуса на сервере приложения с последующим запросом к реверс-прокси на перенаправление к нужному скрипту, что несколько похоже на «подмену» файла.
В любом случае, у меня создалось впечатление, что вы рассматриваете сборку, как нечто динамическое. Вот пришел авторизованный клиент, собираем для него админский набор. Иначе — собираем другой. Но сборка-то едина и статична для всех сценариев.

Delphinum 1 сен 2015 в 17:46

Не совсем так. Просто у webpack проблема в том, что его пытаются сделать «слишком умным». С одной стороны это удобно, так как не нужно ничего настраивать руками, все есть из коробки, но когда сталкиваешься с подобными задачами понимаешь, что это не панацея.

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

Eternalko 2 сен 2015 в 00:33

это не принципиально.

Принципиально.

Это отделяет возможную к решению задачу от невозможной даже в теории.

Delphinum 2 сен 2015 в 00:49

Принципиально.

Не принципиально, так как проблема, которую я пытаюсь описать, не связана с этим.

Eternalko 2 сен 2015 в 00:38

Проблема в том, что webpack не может сложить проект так, чтобы в нем не осталось ссылок на подключаемые модули (либо я не понял, как это сделать).

webpack может.

// config.js

{
  entry: {
    app: 'app.js',
    output: {
      path: __dirname + "/build/dev/",
      publicPath: "/scripts/",
      filename: '[name].js',
      chunkFilename: '[name].js', // !!!!!!!!!
    },
    target: 'web'
}


// app.js

var nm;
nm = require('normal.js');


require.ensure(["secret"], function(require) {
  var secret = require('secret.js');
  return console.log(adm);
}, 'SecretName'); // !!!!!!!!!