NPM против Бауэра против Browserify против Gulp против Grunt против Webpack

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

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

Вопросов:

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

Webpack и Browserify

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

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

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

Webpack Dev Server

Webpack Dev Server предоставляет решение, аналогичное Browsersync - серверу разработки, на котором вы можете быстро развернуть свое приложение во время работы над ним и немедленно проверить прогресс в разработке, так как сервер dev автоматически обновляет браузер при изменении кода или даже при распространении измененного кода. в браузер без перезагрузки с так называемой горячей заменой модуля.

Исполнители задач против сценариев NPM

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

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

Примеры

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

Говоря более точно, start.jsсоздает как клиентские, так и серверные пакеты, запускает экспресс-сервер и после успешного запуска инициализирует синхронизацию браузера, которая на момент написания выглядела так (см. Новейший код для реакции на стартовый проект ).

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 , и Browsersync запускает сервер, прослушивающий http: // localhost: 3001 , где сгенерированные ресурсы обслуживаются с автоматическим изменением обнаружение и замена горячего модуля. Как вы можете видеть, есть еще одно свойство конфигурации filesс отдельными файлами или шаблонами. Browser-sync отслеживает изменения и перезагружает браузер, если таковые происходят, но, как говорится в комментарии, 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
});

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

Обновление октябрь 2018

Если вы все еще не уверены в Front-end dev, можете взглянуть на отличный ресурс здесь.

https://github.com/kamranahmedse/developer-roadmap

Обновление июнь 2018

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

https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70

Обновление июль 2017

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

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

Я также искал это довольно давно, так как есть много инструментов, и каждый из них приносит нам пользу в своем аспекте. Сообщество делится на такие инструменты, как 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: для управления пакетами front-end концепция такая же, как и у 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

Беседка

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. А с помощью Yarn вы все равно можете использовать NPMи Bowerреестр, и получить пакет. Если вы установили пакет ранее, yarnсоздайте кэшированную копию, что облегчает offline package installs.

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

Смотрите различие между Bowerи jspm: Диспетчер пакетов: Bower против JSPM

2. Модуль Загрузчик / Комплектация

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

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

Например

<head>
    <title>Wagon</title>
    <script src=“build/wagon-bundle.js”></script>
</head>

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

Например

<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пакет модулей: это полностью инструмент времени сборки, создающий пакет кода, который затем может быть загружен на стороне клиента.

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

npm install -g –save-dev browserify

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

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

И когда все в порядке, введите команду bundle:

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). Он построен поверх ES6polyfill загрузчика модулей и достаточно умен, чтобы определять используемый формат и обрабатывать его соответствующим образом. SystemJSтакже может переносить код ES6 (с помощью Babelили Traceur) или другие языки, такие как TypeScriptи CoffeeScriptс помощью плагинов.

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

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

• https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a0a9#.c1q7ao3h4
• http://jamesknelson.com/which-build-system-should-i-use-for-my-javascript-app/
• https://appendto.com/2016/06/the-short-history-of-javascript-module-loaders/

Почему jspmи SystemJS?

Одной из главных целей ES6модульности, чтобы сделать его очень просто установить и использовать любую библиотеку Javascript из любой точки интернета ( Github, npmи т.д.). Нужны только две вещи:

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

Таким образом jspm, вы можете сделать это.

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

display.js

var $ = require('jquery'); 

$('body').append("I've imported jQuery!");

3. Затем вы настраиваете эти вещи внутри, System.config({ ... })прежде чем импортировать свой модуль. Обычно при запуске jspm initбудет файл с именем config.jsдля этой цели.

4. Чтобы эти скрипты запускались, нам нужно загрузить 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. Задача бегуна

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

• 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с потоками, как это приложение узла. Предпочитаю эти дни.

Это 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, шрифты. Вы можете просто установить yeomanи запустить простой скрипт. Тогда все здесь для вас.

Узнайте больше здесь .

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, я всегда вижу вопрос сверху, поэтому я решил ответить на него вкратце. Надеюсь, вы, ребята, нашли это полезным.

Хорошо, у них всех есть некоторые сходства, они делают одно и то же для вас по-разному и похожим образом, я делю их на 3 основные группы, как показано ниже:

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

WebPack

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

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

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

больше здесь

browserify

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

больше здесь

2) Задачи бегунов

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

глоток

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

больше здесь

хрюкать

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

больше здесь

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

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

НПМ

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

больше здесь

беседка

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

больше здесь

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

пряжа

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

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

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

больше здесь

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

Сравнение browserify против grunt против gulp против webpack

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

Так что, если нужно выбрать одно из другого, я бы пошел с Gulp

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

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

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

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

Этот проект в значительной степени вдохновлен инструментом модульного тестирования nof5 .

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

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

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

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

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

Когда бы вы использовали gulp / grunt поверх npm + plugins?

Вы можете забыть 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 или аналогичные инструменты.

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

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

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одного можно пойти с нативным 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.