Можно ли связывать файлы модулей узлов в webpack.config.js?

Question

В некоторых проектах я видел, что разработчики не ссылались на файлы node_modules в webpack.config.js (например, "./node_modules/boostrap/dist/js/boostrap.bundle.js"), вместо этого они скопировали файл в assets / js и связал его там. Некоторые из моих друзей также сказали мне, что они предпочитают эту опцию, потому что они никогда не чувствуют себя в безопасности при связывании с node_modules (я думаю, поскольку кто-то может использовать npm update ...?)

Что бы вы назвали «хорошей практикой»? Это нормально для ссылки на node_modules? Если нет - что плохого может случиться?

Я использовал этот метод в небольших проектах, так как я не думаю, что есть необходимость в дублировании файлов, но в больших - для спокойствия - я использовал путь к активам

Answer 1

Это может быть хорошо, чтобы сделать это.Чисто с точки зрения шага сборки, это не имеет значения.

Компромиссы, которые вы делаете между использованием модулей узлов, когда npm предоставляет их (node_modules), и хранением ваших собственных копий в assetsили vendors папка, о:

1. безопасность
2. управление исходным кодом и эффективность разработки
3. пространство для хранения

Когда всетысячи разработчиков по всему миру создают небольшие проекты для домашних животных и отправляют их в Github, для всех них не имеет смысла хранить свою собственную копию JQuery и затем помещать ее в свое репозиторий Github.Вместо этого мы помещаем файл package.json, который перечисляет его как зависимость, мы делаем это для каждой сторонней зависимости и предотвращаем создание хранилища, где большая часть (даже большая часть) кода - это не код приложения, а зависимости.Это хорошо.

С другой стороны, если разработчик всегда загружает зависимости каждый раз, когда новый проект запускается / клонируется / разветвляется, вы рискуете, при каждой загрузке модуля, вероятность установки скомпрометированной версии пакета.,Для этого мы используем сканеры уязвимостей, семантическое управление версиями и блокировку файлов (package-lock.json), чтобы дать вам контроль над тем, как и когда вы получаете обновления.

Другая проблема с загрузкой всегда связана с используемой полосой пропускания.Для этого мы решаем с локальным кешем.Таким образом, даже если вы удалите модуль из одного проекта, npm на самом деле не удалит его с вашего диска.Он хранит копию в папке кэша.Это работает очень хорошо для большинства разработчиков, но не так сильно в корпоративной среде с массивными приложениями.

Проблема, которая серьезно повлияла уже на мир, состоит в том, что если автор модуля решит удалить код, то многоприложений перестают работать, потому что они больше не могут найти зависимость.См. сломанный левый блок Узел, Вавилон ... (Это также сломало вещи на моей работе)

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

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