it-roy-ru.com

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

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

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

Вопросы:

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

Webpack и Browserify

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

Например, допустим, вы написали код 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 Starter Project , которое показывает вам отличную комбинацию сценариев NPM и JS, охватывающих весь процесс сборки и развертывания. Вы можете найти эти сценарии NPM в файле package.json в корневой папке, в свойстве с именем scripts. Там вы в основном встретите такие команды, как babel-node tools/run start. Babel-node - это инструмент CLI (не предназначенный для производственного использования), который сначала компилирует файл ES6 tools/run (файл run.js, расположенный в tools ) - по сути, утилиту runner. Этот бегун принимает функцию в качестве аргумента и выполняет ее, которая в данном случае 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: 30 , и Browsersync запускает прослушивание сервера 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
});

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

934
Dan Macák

Обновление за октябрь 2018 г.

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

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

Обновление за июнь 2018 года

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

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

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

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

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


Почему jspm и SystemJS?

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

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

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

  1. Установите библиотеку с помощью команды: jspm install jquery
  2. Импортируйте библиотеку одной строкой кода, нет необходимости во внешней ссылке внутри вашего 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. Задача бегун

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

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

630
trungk18

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

Сравнение браузерной проверки с ворчанием против gulp против webpack

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

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

49
dcohenb

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

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

41
DeadWoroz

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

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

12
Ellone

Что такое 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?

Вы можете забыть Глоток, Грант, Броколи, Бранч и Бауэр . Вместо этого напрямую используйте сценарии командной строки 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 или аналогичные инструменты.

12
prosti

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.

9
Dmitry Sheiko