Webpack и связанная с ним цепочка инструментов прекрасно помогают вам эффективно связать ваш JavaScript, но я обнаружил, что начальная документация и различные вводные статьи не очень хорошо соответствуют реальным проблемам, с которыми я столкнулся при создании своих первых веб-пакетов. Вот несколько советов по устранению распространенных проблем с пакетированием.

Внешние библиотеки во времена перехода на JavaScript

Вы хотите написать некоторый код, который вызывает модуль NPM, потому что мы все должны проникнуться религией модулей, верно? — но когда вы упаковываете его, все, что вы видите, это пустая или частично отключенная страница.

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

Если бы мне пришлось назвать источник проблем и путаницы Webpack для новых пользователей № 1, я бы назвал импорт вместо требуемых модулей. К сожалению, именно здесь всплывает тот факт, что JavaScript находится в серьезном переходном состоянии, и начинает кусать вас как скромного разработчика, который просто хочет довести дело до конца. Я предлагаю вам просто постараться относиться к этому как к дзен и позволить всем словам о модулях ES5, ECMAScript 2015, CommonJS, AMD и ES6 просто захлестнуть вас. Что вам нужно знать, так это то, что мы все переходим на модули ES6, но этого еще не произошло… и в мире, где мы все стали зависимы от сотен, если не тысяч модулей NPM с различными графиками обслуживания, это не так. Это будет легкий или быстрый переход.

Вы можете «импортировать» код только в том случае, если вы на 100% уверены, что он совместим с ES6. Если есть какие-либо сомнения, особенно если консоль выдает ошибку, похожую на «Uncaught ReferenceError: [модуль] не определен», вы можете вместо этого попробовать синтаксис Node «require». На мой взгляд, Require немного сложнее, и это временный псевдостандарт, который со временем исчезнет… но если в документации модуля он упоминается, сначала попробуйте.

Импорт/требование в нужном месте

Иногда у вас может быть цепочка из трех или четырех компонентов, которые вы включаете, и вы можете потерять представление о том, какие именно файлы нуждаются в том, какие модули импортированы или требуются. У этого есть очень простое решение: включайте все при каждой мыслимой возможности, а затем используйте webpack.optimize.DedupePlugin в вашем webpack.config.js для дедупликации (хотя, честно говоря, дедупликация все еще довольно сырая и может вызвать серьезные проблемы).

Внешний вид

Тот факт, что вы импортируете/требуете модуль, не означает, что он окажется в вашей сборке Webpack. Проверьте наличие раздела externals в вашем файле webpack.config.js. Любой модуль там должен вызываться старыми добрыми тегами script. jQuery является здесь классическим примером: даже если вам нужно импортировать jquery поверх всех ваших компонентов, которые его используют, ваш код фактически будет вызывать его из тега script в вашем HTML-файле верхнего уровня (так что он может кэшироваться браузером). ), а не встраивать его в свои пакеты Webpack.

Более продвинутая отладка

Я столкнулся со случайным дерганьем при некоторых попытках сборки — например, в одном случае я мог заставить пакет работать, только если я включил его ЛИБО в элемент head или после тега, который его вызвал — так что не бойтесь просто переместить вещи вокруг.

Мне пока не приходилось прибегать ни к одному из этих советов — и некоторые из них довольно страшные! — но они станут следующим шагом в отладке неудачных сборок Webpack.

Вам нужна комплектация? Может быть нет. Ты хочешь этого? Абсолютно да!

Мы находимся в периоде бурного роста цепочки инструментов JavaScript, что привело к тому, что долгосрочный грааль JavaScript стал компилируемым языком со всеми вытекающими последствиями. Естественно, что все это распространение инструментов приводит к большому количеству FUD, особенно потому, что в течение стольких лет большинству программ JavaScript не требовалось ничего, кроме текстового редактора и тега скрипта, связанного с jquery.min.js.

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