Anisov Oct 21 2018 at 19:25

Webpack 4 и разделение конфигурационного файла на модули

3 min

19K

Website development*JavaScript*Build automation*

+14

Comments 11

justboris Oct 21 2018 at 21:21

Хорошая идея про модульное оформление, гораздо лучше читается, но зачем вы используете второй аргумент argv для определения окружения? Официальная документация рекомендует использовать параметр env.

Anisov Oct 21 2018 at 22:14

Модуль exports(module.exports = function(env, argv) ) может быть функцией, которая принимает env(environment) и argv, если сделать console.log(argv) внутри этой функции, и вызвать npm run build вы увидите кучу параметров(опций), в этом js объекте есть знакомый ключ — mode cо значением 'production'. А взялось это из скрипта(файл package.json), мы указывали, что при npm run build нужно использовать -> mode production, при start будет mode development.

justboris Oct 22 2018 at 01:50

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

CuamckuyKot Oct 22 2018 at 01:06

Обратите внимание на пути:

PATHS.source + '/pages/index/index.pug'

Под Windows такого вида unix-пути не заработают.

Правильнее писать так:

const path = require('path');
const merge = require('webpack-merge');
const pug = require('./webpack/pug');

const common = merge([
  {
    entry: {
      'index': path.join(PATHS.source,'pages','index','index.pug'),
      'blog': path.join(PATHS.source,'pages','blog','blog.js'),
    },
    output: {
      path: PATHS.build,
      filename: path.join('.','js','[name].js'),
    },
    plugins: […],
    optimization: { … },

  },
  pug(),
]);

Anisov Oct 22 2018 at 01:50

Данная сборка была разработана под ОС Windows 10, так как большинство времени во front-end разработке проводится именно под этой ОС. В back-end разработке конечно же Linux используется мною как основная и главная ОС, но в данном случает под виндой всё работает идеально. А так замечание справедливое, можно сделать и так, если хочется, но у меня такой надобности не было.

Skerrigan Oct 22 2018 at 05:09

Ну… если уж выкладывать в «public access» что-либо, то все же стоит задаться с самого начала вопросами «привести в порядок». А в это уже входит не «мне было удобно — сделал так, чисто для себя», а «делать как надо». Вы же для людей, а не для себя таки?
P.S. Забавно, ровно то же самое, что и в топике, пилил для своей фирмы еще летом — тогда, по иронии, материала было «кот наплакал» и мигрировать v2->v4 было больно.

UPD:

У вас там 'ошибки' в конфиге есть.

ProvidePlugin на сегодняшний день устарел и не обеспечивает глобальной доступности для jQ. Если вам все же она необходима, тогда использовать нужно такой вариант:

test: require.resolve('jquery'),
                use: [{
                    loader: 'expose-loader',
                    options: 'jQuery'
                },{
                    loader: 'expose-loader',
                    options: '$'
                }]

А в packaje.json прописать что-то такое

«expose-loader»: "^0.7.5",

И вот уже теперь можно будет в консольке написать просто знак $, и jQ нормально будет доступен.
Вы можете спросить «а зачем это надо?», на что сразу отвечу — когда вы подключаете какой-либо плагин jQ вне сборщика, то он не будет иметь доступа до библиотеки при использовании ProvidePlugin.

UPD2: Да и hot-reload неплохо было бы использовать (флаг -w в npm-конфиге)… еще стоило бы прикрутить кеширование (хотя бы в один уровень) — скорость сборки бандлов можно снизить в несколько раз.

Anisov Oct 22 2018 at 09:01

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

Skerrigan Oct 22 2018 at 09:29

не посчитал нужным использовать тут

он приложен как хороший

не для себя, а для общего пользования

Это взаимо-противоречие.
Если вы делаете обучающий материал, то он не должен в себе содержать неправильного/ошибок.
А у вас они есть! Вы исходно предоставляете не правильный вариант — в этом смысл. И вам делают подсказки люди, у которых больше знаний/опыта. Зачем упорно гнуть свою линию (что материал не «об этом»)?
Лучше бы внесли исправления в репозиторий — это ведь по сути универсальные аспекты, без разницы «какой там проект» (иначе вообще тот же jQ и в вашем материале лишний — у людей его может и не быть,… а раз уж вы его подключили, то подключайте верным образом) :)
Ровно то же самое касается и «путей» — без разницы, что у вас Win10 (у меня так же, к слову). Важно писать универсальный вариант, с «правильными» путями.
P.S. Да и в целом — «вселенная node.js» не мой дом родной, я из Java-world, тем не менее… :)

faiwer Oct 22 2018 at 10:06

Скажите, что неправильного в игнорировании path.join в пользу обычной конкатенации unix-like. Насколько я понимаю, проблемы могут возникнуть:

при вызове spawn, exec и пр. внешние запуски других приложений
хитрые махинации с частями путей, полученными из разных источников

Я ничего не упустил? Суть именно во втором пункте? Что-то вроде складывания C:\somepath и otherpath/file.txt?

P.S. вообще не использую path.join (каюсь, грешен), т.к. давным давно не видел Windows на машинах разработчиков, и сам не использую. Хочу понять насколько проблема реально актуальна.

Skerrigan Oct 22 2018 at 10:36

Я ничего не упустил? Суть именно во втором пункте? Что-то вроде складывания C:\somepath и otherpath/file.txt?

Вот конкретно подобное у нас таки «сплошь и рядом» (в основном из-за того, что разные задачи требуют разные суб-инструменты, где бывают предпочтительными разные виды слешей,… ага, как раз тоже «не заморачивались универсальностью»).
За остальное не скажу, лишь, если говорить конкретно о путях, то, что когда сам писал с большей платформо-зависимостью, мне сразу «по рукам стучали» (ибо нефиг привыкать писать «тяп-ляп», лучше один раз написать «как надо» и чтобы потом работало N-лет всегда, надежным образом — и так существует множество ситуаций, когда приходится намеренно писать «плохой код», так зачем это делать еще и, когда можно без этого?).
*у нас судя по всему практически все (за исключением пары машин (одна из которых сервак) — все на Win). У знакомых, в фирмах размера ~>100ч., аналогично — всюду Win. При том, что мизерный процент чего-либо таки на Unix.

оффтоп

P.S. Но исходно речь была немного об ином: что поправки к статье автора ничем не вредят его материалу,… более того, делают материал более верным и полезным. Та же быстрая компиляция в бандл — я не могу назвать человека, которому пригодится именно медленная сборка (а не быстрая).
Но автор считает это «не нужным», не смотря на

интересных решениях, которые помогут вам быстрее собрать сборку

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

UPD: посмотрел быстро поиском по проекту — да, кое-где идет вызов посредством командной строки из php в java (угу, и такой лес присутствует).

dfuse Nov 1 2018 at 01:59

https://github.com/andywer/webpack-blocks не то же самое ли делает?

Show the best of all time