NPM против Bower против Browserify против Gulp против Grunt vs. Webpack

Я пытаюсь обобщить свои знания о самых популярных менеджерах пакетов пакетов, поставщиках пакетов и задачах. Пожалуйста, поправьте меня, если я ошибаюсь:

  • npm и bower - менеджеры пакетов. Они просто загружают зависимости и не знают, как создавать проекты самостоятельно. То, что они знают, это вызвать webpack/gulp/grunt после выбора всех зависимостей.
  • bower похож на npm, но строит сплющенные деревья зависимостей (в отличие от npm, которые делают это рекурсивно). Значение npm выбирает зависимости для каждой зависимости (может получать одно и то же несколько раз), а bower ожидает, что вы вручную включите субзависимости. Иногда bower и npm используются вместе для интерфейсных и back-end соответственно (поскольку каждый мегабайт может иметь значение на интерфейсе).
  • grunt и gulp - это бегуны задач для автоматизации всего, что может быть автоматизировано (т.е. скомпилировать CSS/Sass, оптимизировать изображения, сделать связку и минимизировать/перетащить ее).
  • grunt vs. gulp (походит на maven vs. gradle или конфигурацию против кода). Grunt основан на настройке отдельных независимых задач, каждая задача открывает/обрабатывает/закрывает файл. Gulp требует меньшего количества кода и основывается на потоках Node, что позволяет ему строить цепи цепей (без повторного открытия одного и того же файла) и делает это быстрее.
  • webpack (webpack-dev-server) - для меня это задача с горячей перезагрузкой изменений, которая позволяет забыть обо всех наблюдателях JS/CSS.
  • npm/bower + плагины могут заменять задачи. Их способности часто пересекаются, поэтому есть разные последствия, если вам нужно использовать gulp/grunt поверх плагинов npm+. Но бегуны задач, безусловно, лучше подходят для сложных задач (например, "на каждом сборке создают пакет, переходят с ES6 на ES5, запускают его во всех эмуляторах браузеров, делают скриншоты и развертывают в Dropbox через ftp" ).
  • browserify позволяет упаковывать модули Node для браузеров. browserify vs node require на самом деле AMD против CommonJS.

Вопросы:

  • Что такое webpack и webpack-dev-server? Официальная документация говорит, что это модуль, но для меня это просто бегун. Какая разница?
  • Где бы вы использовали browserify? Разве мы не можем сделать то же самое с импорта node/ES6?
  • Когда вы используете gulp/grunt поверх npm + плагинов?
  • Приведите примеры, когда вам нужно использовать комбинацию
+1203
источник поделиться
9 ответов

Webpack и Browserify выполняют практически ту же работу, которая объединяет ваши модули, которые будут использоваться в среде браузера (хотя вы можете настроить таргетинг на другие среды, например, объединить свой ES6-код на стороне сервера для Node). Например, модуль Node - это функция, которая не существует в браузере, а модули ES 6 еще не реализованы ни в одном браузере, поэтому все должно быть связано. Тем не менее, они различаются по многим параметрам, Webpack предлагает множество инструментов по умолчанию (например, разделение кода), в то время как Browserify может делать это только после загрузки плагинов, но использование обоих приводит к очень похожим результатам. Это сводится к личным предпочтениям (я привык к Webpack). Webpack не является бегунком задач, это просто процессор ваших файлов (он обрабатывает их так называемыми загрузчиками), которые запускаются непосредственно из CLI или с помощью бегуна задач.

webpack-dev-server предоставляет что-то вроде Browser-sync - сервера, на котором вы можете развернуть свое приложение и немедленно проверить ваш прогресс в области разработки FE, когда dev-сервер автоматически обновляет браузер или даже распространяет изменения без него с помощью горячего развертывания (например, компоненты React).

Я использовал Gulp для краткости и простой записи задач, но позже выяснил, что мне не нужны ни Gulp, ни Grunt вообще. Все, что мне когда-либо понадобилось, могло быть сделано с использованием сценариев npm для запуска сторонних инструментов через их API. Выбор между Gulp, скрипты Grunt или npm зависят от вашего вкуса, опыта JS и опыта работы разработчиков с вами.

В то время как задачи в Gulp (или, возможно, Grunt) легко читаются даже для людей, не знакомых с JS, это еще один инструмент, который требует и учится, и я лично предпочитаю сузить свои зависимости и делать вещи простыми. С другой стороны, заменяя эти задачи комбинацией npm-скриптов и файлов запуска (где конфигурация и функция выполнения таких инструментов, как Webpack), сложнее. Но в большинстве случаев эти три равны по результатам.

Что касается примеров, я предлагаю вам взглянуть на этот проект React starter, который показывает вам приятную комбинацию скриптов npm, Webpack и синхронизация браузера. Вы можете найти эти npm-скрипты в package.json в корневой папке в свойстве с именем scripts. Там вы будете чаще встречаться с командами типа babel-node tools/run start. Babel- node - это инструмент CLI (не предназначенный для производственного использования), который сначала компилирует файл ES6 tools/run (файл run.js, расположенный в tools) - в основном утилита runner. Этот бегун принимает функцию в качестве аргумента и запускает ее, которая в этом случае start - другая утилита (start.js), ответственная за связывание исходных файлов (как с клиентом, так и с сервером), начиная с сервера node -express, а затем Браузер-синхронизация, которая служит прокси-сервером для распространения изменений разработки в браузере.

Говоря более точно, start.js импортирует конфигурацию Webpack для клиента, манипулирует ею для добавления возможностей замены горячего модуля, а затем создает как пакеты клиентов, так и серверы, запускает сервер Node через еще одну утилиту с именем runServer.js и после успешной запустите inits Browser-sync, который выглядит примерно так.

const bs = Browsersync.create();  
bs.init({
      ...(DEBUG ? {} : { notify: false, ui: false }),

      proxy: {
        target: host,
        middleware: [wpMiddleware, ...hotMiddlewares],
      },

      // no need to watch '*.js' here, webpack will take care of it for us,
      // including full page reloads if HMR won't work
      files: ['build/content/**/*.*'],
}, resolve)

Важной частью является proxy.target, где вы задаете адрес сервера, который вы хотите прокси, который может быть http://localhost:3000, а Browser- sync запускает сервер, прослушивающий http://localhost:3001, где развертывается одно и то же приложение, но с горячей заменой модуля, поэтому вы можете столкнуться с распространением исходного файла Изменения в браузере немедленно или даже без перезагрузки. Как вы можете видеть, существует еще одно свойство конфигурации files с отдельными файлами или шаблонами. Браузер-синхронизация часов для изменений и перезагрузки браузера, если они встречаются, но, как говорится в комментарии, Webpack заботится о том, чтобы просматривать js-источники самостоятельно с помощью HMR, поэтому они там сотрудничают.

Теперь у меня нет эквивалентного примера такой конфигурации Grunt или Gulp, но с Gulp (и несколько аналогично с Grunt) вы должны писать отдельные задачи в gulpfile.js, например

gulp.task('bundle', function() {
  // bundling source files with some gulp plugins like gulp-webpack maybe
});

gulp.task('start', function() {
  // starting server and stuff
});

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

+643
источник

Я также искал это довольно давно, так как там есть много инструментов, и каждый из них приносит нам пользу в другом аспекте. Сообщество делится на такие инструменты, как Browserify, Webpack, jspm, Grunt and Gulp. Вы также можете услышать о Yeoman or Slush. Это не проблема, а просто путаница для всех, кто пытается понять четкий путь вперед.

В любом случае, я хотел бы внести свой вклад.

1. Менеджер пакетов

Менеджеры пакетов упрощают установку и обновление зависимостей проектов, таких как: jQuery, Bootstrap и т.д. - все, что используется на вашем сайте и не написано вами.

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

  • NPM означает: Node JS package manager помогает вам управлять всеми библиотеками, на которые опирается ваше программное обеспечение. Вы должны определить свои потребности в файле с именем package.json и запустить npm install в командной строке... затем BANG, ваши пакеты будут загружены и готовы к использованию. Может использоваться как для библиотек front-end and back-end.

  • Bower: для управления интерфейсом переднего плана концепция аналогична с NPM. Все ваши библиотеки хранятся в файле с именем bower.json, а затем запустите bower install в командной строке.

Самое большое различие между Bower и NPM заключается в том, что NPM выполняет вложенные дерева зависимостей, тогда как для Bower требуется плоское дерево зависимостей, как показано ниже.

Цитата из В чем разница между Bower и npm?

NPM

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Bower

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Есть несколько обновлений на npm 3 Duplication and Deduplication, пожалуйста, откройте документ для более подробной информации.

  • Yarn: новый менеджер пакетов для JavaScript опубликован в Facebook с еще несколькими преимуществами по сравнению с NPM. И с пряжей вы все равно можете использовать NPM и Bower, чтобы получить пакет. Если вы установили пакет раньше, Yarn создает кешированную копию, которая облегчает offline package installs.

  • jspm: это менеджер пакетов для универсального загрузчика модулей SystemJS, построенный поверх динамического ES6 загрузчик модулей. Это не совсем новый менеджер пакетов с собственным набором правил, скорее он работает поверх существующих источников пакетов. Из коробки он работает с GitHub и NPM. Поскольку большинство пакетов на основе Bower основаны на GitHub, мы можем установить эти пакеты с помощью jspm. В нем есть реестр, в котором перечислены большинство распространенных интерфейсных пакетов для упрощения установки.

Смотрите разницу между Bower и jspm: Менеджер пакетов: Bower vs jspm


2. Модуль загрузчика/группировки

В большинстве проектов любого масштаба их код разделяется между несколькими файлами. Вы можете просто включить каждый файл с отдельным тегом <script>, однако <script> устанавливает новое http-соединение, а для небольших файлов - цель модульности - время для установления соединения может занять значительно больше времени, чем перенос данные. Пока скрипты загружаются, на странице не может быть изменен контент.

  • Проблема времени загрузки может быть решена путем объединения одной группы простых модулей в один файл и ее минимизации.

например

<head>
    <title>Wagon</title>
    <script src="build/wagon-bundle.js"></script>
</head>
  • Производительность приходит за счет гибкости. Если ваши модули имеют взаимозависимость, это отсутствие гибкости может быть showstopper.

например

<head>
    <title>Skateboard</title>
    <script src="connectors/axle.js"></script>
    <script src="frames/board.js"></script>
    <!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing -->
    <script src="rolling-things/abstract-rolling-thing.js"></script>
    <script src="rolling-things/wheels/skateboard-wheel.js"></script>
    <!-- but if skateboard-wheel also depends on ball-bearing -->
    <!-- then having this script tag here could cause a problem -->
    <script src="rolling-things/ball-bearing.js"></script>
    <!-- connect wheels to axle and axle to frame -->
    <script src="vehicles/skateboard/our-sk8bd-init.js"></script>
</head>

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

Затем мы услышали о RequireJS, Browserify, Webpack и SystemJS

  • RequireJS: это загрузчик файлов и модулей JavaScript. Он оптимизирован для использования в браузере, но его можно использовать в других средах JavaScript, например Node.

Например: myModule.js

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

В main.js мы можем импортировать myModule.js в качестве зависимости и использовать его.

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

И затем в нашем HTML, мы можем ссылаться на использование с RequireJS.

<script src="app/require.js" data-main="main.js" ></script>

Узнайте больше о CommonJS и AMD, чтобы легко понять. Связь между CommonJS, AMD и RequireJS?

  • Browserify: укажите, чтобы разрешить использование CommonJS отформатированных модулей в браузере. Следовательно, Browserify не столько загрузчик модулей, сколько модуль-модуль: Browserify - это инструмент времени сборки, создающий пакет кода, который затем может быть загружен на стороне клиента.

Начните с машины сборки, на которой установлены node и npm, и получите пакет:

npm install -g –save-dev browserify

Запишите свои модули в формате CommonJS

//entry-point.js
var foo = require('../foo.js');
console.log(foo(4));

И когда вы счастливы, выполните команду для объединения:

browserify entry-point.js -o bundle-name.js

Browserify рекурсивно находит все зависимости точки входа и собирает их в один файл:

<script src="bundle-name.js"></script>
  • Webpack: он объединяет все ваши статические активы, включая JavaScript, изображения, CSS и многое другое, в один файл. Он также позволяет обрабатывать файлы с помощью различных типов загрузчиков. Вы можете написать свой JavaScript с синтаксисом модулей CommonJS или AMD. Он атакует проблему сборки в принципиально более интегрированной и упрямой манере. В Browserify вы используете Gulp/Grunt и длинный список преобразований и плагинов, чтобы выполнить задание. Webpack предлагает достаточно мощности из коробки, в которой обычно не требуется Grunt или Gulp вообще.

Основное использование не просто. Установите Webpack как Browserify:

npm install -g –save-dev webpack

И передайте команде точку входа и выходной файл:

webpack ./entry-point.js bundle-name.js
  • SystemJS: является загрузчиком модуля, который может импортировать модули во время выполнения в любом из популярных форматов используется сегодня (CommonJS, UMD, AMD, ES6). Он построен поверх загрузчика модуля ES6 polyfill и достаточно умен, чтобы определить используемый формат и обрабатывать его соответствующим образом. SystemJS также может транслировать код ES6 (с Babel или Traceur) или другими языками, такими как TypeScript и CoffeeScript с использованием плагинов.

Хотите узнать, что такое node module и почему он плохо адаптирован для браузера.

Более полезная статья:


Почему jspm и SystemJS?

Одна из основных целей модульности ES6 заключается в том, чтобы сделать ее действительно простой для установки и использования любой библиотеки Javascript из любого места на Интернет (GitHub, NPM и т.д.). Требуется только две вещи:

  • Одна команда для установки библиотеки
  • Одна строка кода для импорта библиотеки и ее использования

Итак, с помощью jspm вы можете сделать это.

  • Установите библиотеку с помощью команды: jspm install jquery
  • Импортировать библиотеку с одной строкой кода, без необходимости внешней ссылки внутри HTML файла.

display.js

var $ = require('jquery'); 

$('body').append("I've imported jQuery!");
  1. Затем вы настраиваете эти вещи в System.config({ ... }) до импортируя ваш модуль. Обычно при запуске jspm init будет файл названный config.js для этой цели.

  2. Чтобы эти сценарии выполнялись, нам нужно загрузить system.js и config.js на странице HTML. После этого мы загрузим файл display.js, используя загрузчик модуля SystemJS.

index.html

<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
  System.import("scripts/display.js");
</script>

Отмечено: вы также можете использовать NPM с Webpack, поскольку Angular 2 применил его. Поскольку jspm был разработан для интеграции с SystemJS, и он работает поверх существующего источника NPM, поэтому ваш ответ зависит от вас.


3. Задача

Задачи и инструменты сборки - это в первую очередь инструменты командной строки. Почему мы должны использовать их: одним словом: автоматизация. Чем меньше работы вы выполняете при выполнении повторяющихся задач, таких как минимизация, компиляция, модульное тестирование, linting, которые ранее стоили нам много раз, чтобы делать с командной строкой или даже вручную.

  • Grunt: вы можете создавать автоматизацию для своей среды разработки для предварительного кода или создавать скрипты сборки с помощью файла конфигурации, и кажется очень сложно справиться с сложной задачей. Популярный в последние несколько лет.

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

grunt.initConfig({
  clean: {
    src: ['build/app.js', 'build/vendor.js']
  },

  copy: {
    files: [{
      src: 'build/app.js',
      dest: 'build/dist/app.js'
    }]
  }

  concat: {
    'build/app.js': ['build/vendors.js', 'build/app.js']
  }

  // ... other task configurations ...

});

grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);
  • Gulp: автоматизация, как и Grunt, но вместо конфигураций вы можете написать JavaScript с потоками вроде node приложение. Предпочитаю в эти дни.

Это объявление образца Gulp.

//import the necessary gulp plugins
var gulp = require('gulp');
var sass = require('gulp-sass');
var minifyCss = require('gulp-minify-css');
var rename = require('gulp-rename');

//declare the task
gulp.task('sass', function(done) {
  gulp.src('./scss/ionic.app.scss')
    .pipe(sass())
    .pipe(gulp.dest('./www/css/'))
    .pipe(minifyCss({
      keepSpecialComments: 0
    }))
    .pipe(rename({ extname: '.min.css' }))
    .pipe(gulp.dest('./www/css/'))
    .on('end', done);
});

Подробнее: https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4#.fte0nahri


4. Инструменты для строительных лесов

  • Slush and Yeoman: Вы можете создавать с ними стартовые проекты. Например, вы планируете создавать прототип с помощью HTML и SCSS, а затем вручную создавать некоторые папки, такие как scss, css, img, fonts. Вы можете просто установить yeoman и запустить простой script. Тогда все здесь для вас.

Найдите здесь.

npm install -g yo
npm install --global generator-h5bp
yo h5bp

Подробнее: https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express


Мой ответ не совсем соответствует содержанию вопроса, но когда я ищу эти знания в Google, я всегда вижу вопрос, и я решил ответить на него вкратце, а также почему мы должны использовать эти инструмент.

Недавно я нашел действительно полное руководство от команды Grab о том, как приблизиться к разработке интерфейса в 2017 году. Вы можете проверить это, как показано ниже.

https://github.com/grab/front-end-guide

+443
источник
другие ответы

Связанные вопросы


Похожие вопросы

Вы можете найти техническое сравнение npmcompare

Сравнение прокрутки браузера против хрюка vs. gulp vs. webpack

Как вы можете видеть, webpack очень хорошо поддерживается с новой версией, выходящей каждые 4 дня в среднем. Но gulp, похоже, имеет самое большое сообщество из всех (с более чем 20 000 звезд в Github) Грунт кажется немного пренебрегаемым (по сравнению с другими)

Поэтому, если нужно выбрать один над другим, я бы пошел с Gulp

+36
источник

Небольшое примечание о npm: npm3 пытается установить зависимости плоским способом.

https://docs.npmjs.com/how-npm-works/npm3#npm-v3-dependency-resolution

+35
источник

ОК, все они имеют некоторые общие черты, они делают то же самое для вас разными и похожими способами, я разделяю их на 3 основные группы, как показано ниже:


1) Модульные модули

webpack и браузеризировать как популярные, работайте как бегуны задач, но с большей гибкостью, а также объедините все вместе как свою настройку, так что вы можете указать на результат как bundle.js, например, в одном файле, включая CSS и Javascript, для получения более подробной информации о каждом из них, смотрите ниже:

WebPack

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

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

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

подробнее здесь

browserify

Browserify - это инструмент разработки, который позволяет нам писать node.js-style модули, которые компилируются для использования в браузере. Подобно node, мы пишем наши модули в отдельных файлах, экспорт внешних методов и с использованием переменных module.exports и экспорта. Мы можем даже требуют использования других модулей с использованием функции require, и если мы опустим относительный путь itll разрешает модуль в node_modulesкаталог.

далее здесь


2) Бегуны задач

gulp и хрюкать - это бегуны задач, в основном то, что они делают, создавая задачи и запуская их, когда захотите, например, вы устанавливаете плагин, чтобы минимизировать свой CSS, а затем запускать его каждый раз, чтобы сделать минимизацию, более подробную информацию о каждом:

gulp

gulp.js - инструментарий JavaScript с открытым исходным кодом от Fractal Innovations и сообщество с открытым исходным кодом в GitHub, используемое как потоковая сборка системы в интерфейсе веб-разработки. Это задача, построенная на node.js и Node Менеджер пакетов (npm), используемый для автоматизации трудоемкие и повторяющиеся задачи, связанные с веб-разработкой, такими как минимизация, конкатенация, сбой кэша, модульное тестирование, листинг, оптимизация и т.д. gulp использует подход с кодовой конфигурацией для определить свои задачи и полагаться на свои малые однонаправленные плагины на вынести их. В экосистеме gulp имеется более 1000 таких плагинов на выбор.

далее здесь

хрюкать

Grunt - это бегун для задач JavaScript, инструмент, используемый для автоматического выполнять часто используемые задачи, такие как минимизация, компиляция, единица тестирование, листинг и т.д. Он использует интерфейс командной строки для запуска пользовательских задачи, определенные в файле (известный как файл Grunt). Grunt был создан Бен Альман и написан в node.js. Он распространяется через npm. В настоящее время доступно более пяти тысяч плагинов в Grunt экосистема.

more здесь


3) Менеджеры пакетов

Менеджеры пакетов

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

NPM

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

далее здесь

Беседка

Bower может управлять компонентами, которые содержат HTML, CSS, JavaScript, шрифты или даже файлы изображений. Bower не объединяет или не уменьшает код или не делает ничего другого - он просто устанавливает правильные версии пакетов вам нужны и их зависимости. Чтобы начать работу, Bower работает, выбирая и устанавливая пакеты из во всем, заботясь о охоте, поиске, загрузке и сохранении вещи, которые вы ищете. Bower отслеживает эти пакеты в файл манифеста, bower.json.

подробнее здесь

и самый последний менеджер пакетов, который не следует упускать, он молод и быстр в реальной рабочей среде по сравнению с npm, который я в основном использовал раньше, для переустановки модулей он дважды проверяет папку node_modules, чтобы проверить наличие модуля, также кажется, что установка модулей занимает меньше времени:

пряжа

Пряжа - это менеджер пакетов для вашего кода. Это позволяет использовать и совместно использовать другие разработчики со всего мира. Пряжа делает это быстро, надежно и надежно, поэтому вам никогда не придется беспокоиться.

Пряжа позволяет использовать другие разработчики для разных проблемы, облегчая вам разработку вашего программного обеспечения. если ты есть проблемы, вы можете сообщить о проблемах или внести свой вклад, а проблема исправлена, вы можете использовать пряжу, чтобы поддерживать ее в актуальном состоянии.

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

далее здесь



+19
источник

Что такое webpack и webpack-dev-сервер? Официальная документация говорит, что это модуль, но для меня это просто бегун. Какая разница?

webpack-dev-server - это живой перезагружающийся веб-сервер, который разработчики Webpack используют для немедленной обратной связи с тем, что они делают. Его следует использовать только во время разработки.

Этот проект сильно вдохновлен инструментом nof5 unit test.

Webpack, как следует из названия, создаст для веб-сайта стиль SINGLE pack.. Пакет будет сведен к минимуму и объединен в один файл (мы все еще живем в возрасте HTTP 1.1). Webpack делает магию объединения ресурсов (JavaScript, CSS, изображения) и вводит их следующим образом: <script src="assets/bundle.js"></script>.

Его также можно назвать модулем связывания модулей, поскольку он должен понимать зависимости модулей и как захватывать зависимости и связывать их вместе.

Где вы будете использовать браузер? Не можем ли мы сделать то же самое с импортированием node/ES6?

Вы можете использовать Browserify в тех же самых задачах, где вы бы использовали Webpack. Однако Webpack более компактен.

Обратите внимание, что функции загрузчика модуля ES6 в Webpack2 используют System.import, который не поддерживает один браузер.

Когда вы используете gulp/grunt над npm + плагинами?

Вы можете забыть Gulp, Grunt, Brokoli, Brunch и Bower. Непосредственно используйте сценарии командной строки npm, и вы можете устранить дополнительные пакеты, подобные этим здесь, для Gulp:

var gulp        = require('gulp'),
  minifyCSS     = require('gulp-minify-css'),
  sass          = require('gulp-sass'),
  browserify    = require('gulp-browserify'),
  uglify        = require('gulp-uglify'),
  rename        = require('gulp-rename'),
  jshint        = require('gulp-jshint'),
  jshintStyle   = require('jshint-stylish'),
  replace       = require('gulp-replace'),
  notify        = require('gulp-notify'),

Вы можете использовать генераторы файлов Gulp и Grunt при создании файлов конфигурации для вашего проекта. Таким образом, вам не нужно устанавливать Yeoman или аналогичные инструменты.

+8
источник

Пряжа - это недавний менеджер пакетов, который, вероятно, заслуживает упоминания. Итак, там: https://yarnpkg.com/

Afaik, он может извлекать зависимости npm и bower и имеет другие важные функции.

+7
источник

StackShare предоставляет бок о бок (или стек вверх) из трех инструментов за один раз.

Здесь для npm vs. Bower vs. Browserify и для gulp против Webpack vs. Grunt

На этих страницах сравнения вы можете найти следующее:

  • количество голосов, полученных каждым из сообщества StackShare
  • какие компании используют их в своем техническом стеке
  • уровень интереса для каждого с течением времени
  • профи для каждого инструмента
+2
источник

Webpack является расслоением. Подобно Browserfy, он ищет в кодовой базе для запросов модуля (require или import) и рекурсивно решает их. Более того, вы можете настроить Webpack для решения не только JavaScript-подобных модулей, но и CSS, изображений, HTML, буквально всего. Что особенно меня волнует Webpack, вы можете комбинировать как скомпилированные, так и динамически загружаемые модули в одном приложении. Таким образом, вы получаете реальное повышение производительности, особенно по HTTP/1.x. Как именно вы это делаете, я описал здесь примеры http://dsheiko.com/weblog/state-of-javascript-modules-2017/ В качестве альтернативы для связки можно подумать о Rollup.js (https://rollupjs.org/), который оптимизирует код во время компиляции, но удаляет все найденные неиспользованные куски.

Для AMD вместо RequireJS можно перейти с native ES2016 module system, но загрузиться с помощью System.js (https://github.com/systemjs/systemjs)

Кроме того, я хотел бы указать, что npm часто используется как средство автоматизации, например grunt или gulp. Проверьте https://docs.npmjs.com/misc/scripts. Я лично перехожу теперь с npm-скриптами, избегая при этом других инструментов автоматизации, хотя в прошлом я был очень в grunt. С помощью других инструментов вам приходится полагаться на бесчисленные плагины для пакетов, которые часто не хорошо написаны и не поддерживаются активно. npm знает свои пакеты, поэтому вы вызываете любой из локально установленных пакетов по имени, например:

{
  "scripts": {
    "start": "npm http-server"
  },
  "devDependencies": {
    "http-server": "^0.10.0"
  }
}

На самом деле вам, как правило, не нужен плагин, если пакет поддерживает CLI.

+1
источник

Посмотрите другие вопросы по меткам или Задайте вопрос