Эта статья была впервые опубликована на личномGithub, вопросы/fxxk приветствуются.

предисловие

В последней статье серии «Как разработать симпатичный интерфейс командной строки (1)» я рассказал вам, как разработать простой инструмент для формирования шаблонов, который генерирует, визуализирует и конвертирует шаблонные файлы (Boilerplate). Эта статья будет приятной продвинутой частью - как основываться наwebpackНапишите инструмент командной строки с нулевой конфигурацией (назовем егоlovely-cli.), для достижения следующих функций:

lovely-cli dev    # 以开发环境，webpack watch的模式启动一个应用
lovely-cli build  # 以生产环境的模式构建应用

Во-первых, я хочу еще раз подчеркнуть концепцию. Хотя у меня есть замечания в первой статье:

“由于脚手架的英文 scaffolding 太长，本文我将以更可爱的 CLI 来代替。”

Но некоторые студенты все равно задавали вопросы (один одноклассник ответил, что я не видел, потому что обычно катаюсь слишком быстро...), поэтому в начале второй статьи я еще раз спросилCLI,ScafolldingКонцепция полностью разработана один раз:

CLI, его полное название — Command-Line Interface, то есть интерфейс командной строки. Ваш обычный git — более известный инструмент командной строки (вы используете Source Tree party, когда я не говорил):

Scaffolding, его английский перевод - Scafollding, о его концепции, пожалуйста, сначала посмотрите на эту картинку:

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

Если вы строите только 1-этажное бунгало, вам может понадобиться только лестница; если это 10 этажей, строительных лесов на картинке выше может быть достаточно; но если это 50 этажей, 100 этажей, ваши леса очень важны для конструкция, несущая, Соображений по безопасности будет больше (ПС: надо хотя бы добавить лифт.)

Вернемся к программированию. Почему концепция скаффолдинга начала распространяться в области фронтенда? В конце концов, все это связано с подъемом машиностроения. С развитием экономики и повышением уровня жизни людей у богатых людей все выше и выше требования к программному опыту, а страницы интерфейса становятся все более и более сложными.Сейчас на это могут уйти сотни, а может и тысячи (плачу ). Позже появился Node, появилась модульность, появились инструменты планирования задач и построения, и зародился фронтенд-инжиниринг, а скаффолдинг играл ту же роль, что и в строительном инжиниринге — помогая вам построить базовую среду разработки, содержащую базовую конфигурацию и скрипты для создать базовую структуру проекта, базовый код и процесс разработки.

А vue-cli, во-первых, это CLI, во-вторых, это Scafollding, после 3.0 его можно рассматривать как инструмент сборки.

Итак, перестаньте спрашивать меня, почему в заголовке не используются строительные леса.

анализировать

Вернемся к нашим требованиям:

lovely-cli dev    # 以开发环境，webpack watch的模式启动一个应用
lovely-cli build  # 以生产环境的模式构建应用

В соответствии с требованиями мы можем разделить следующие подзадачи и задать соответствующие вопросы:

Как написать глобально доступную команду CLI nice-cli с узлом?
Как поддерживать подкоманды (dev, build)?
Как заставить dev запускать webpack dev и строить для запуска webpack build?

воплощать в жизнь

Первые два требования, я полагаю, что большинство программистов интерфейсов/узлов имеют определенное понимание или хорошо знакомы с ними, вот статья г-на Руана.«Учебник по разработке программы командной строки Node.js»В качестве справки студенты, которые забыли, пересматривают его. Я пройдусь по нему быстро:

задача первая

Структура нового проекта выглядит следующим образом:

lovely-cli
├── package.json
└── src
    └── index.js

index.js:

#!/usr/bin/env node

console.log('I am a lovely CLI')

Содержимое package.json следующее:

{
  "name": "lovely-cli",
  "version": "0.0.1",
  "description": "A lovely CLI",
  "bin": "src/index.js"
}

ссылка sudo npm, см. это, это означает, что глобальная регистрация прошла успешно.

/usr/local/bin/lovely-cli -> /usr/local/lib/node_modules/lovely-cli/src/index.js
/usr/local/lib/node_modules/lovely-cli -> /Users/haolchen/Documents/__self__/lovely-cli

ОК, запустите его:

задача вторая

Измените index.js следующим образом:

#!/usr/bin/env node

const command = process.argv[2] // 不懂为什么这样写的同学不够可爱哦，请回去复习。

if (command === 'dev') {
  console.log('Running in development mode.')
} else if (command === 'build') {
  console.log('Running in production mode.')
} else {
  console.log('I am a lovely CLI.')
}

Запустить его:

Примечание. Поскольку параметр командной строки handle не рассматривается в этой статье, демонстрации в этой статье будут демонстрироваться в vanilla node.js. Вы можете использовать старые библиотеки, такие как yargs, command.js и т. д., но я рекомендую прекрасный эгоистcac.

задача третья

Это основное внимание в этой статье, Я считаю, что студенты, которые заинтересованы в этом, должны уже иметь представление:

Запустите nice-cli dev => запустите приложение webpack с помощью webpack-dev-server с конфигурацией среды разработки.
Запускайте nice-cli build => используйте конфигурацию среды сборки и стройте напрямую с помощью webpack.

Первая пряжа:

yarn add webpack webpack-dev-server -D

Далее просто покажите код:

//  20行伪代码实现一个 lovely-cli
#!/usr/bin/env node

const command = process.argv[2]
const Webpack = require('webpack')
const WebpackDevServer = require('webpack-dev-server')

const defaultDevConfig = {} 
const defaultProdConfig = {} 

if (command === 'dev') {
  const compiler = Webpack(defaultDevConfig)
  const devServerOptions = defaultDevConfig.devServer
  const devServer = new WebpackDevServer(compiler, devServerOptions)
  devServer.listen(8080, 'localhost', () => console.log('Starting server on http://localhost:8080'));

} else if (command === 'build') {
  Webpack(defaultProdConfig)

} else {
  console.log('I am a lovely CLI.')
}

Это очень просто Теперь, когда у нас есть все идеи, давайте продолжим улучшать код и напишем простую и удобную версию.

Во-первых, улучшите структуру проекта:

lovely-cli
├── package.json
├── index.html （新增）
├── package.json
├── src
│   ├── default-webpack-config.js （新增）
│   ├── entry.js （新增）
│   └── index.js
└── dist （新增）

Среди них около 4 новых файлов:

index.html: запись страницы, вы также можете использовать HtmlWebpackPlugin для ее решения;
default-webpack-config.js: конфигурация веб-пакета по умолчанию;
entry.js: запись кода клиента;
dist: выходной каталог.

Сначала взгляните на default-webpack-config.js:

'use strict'

const { resolve } = require('path')

module.exports = {
  entry: resolve(__dirname, 'entry.js'),
  output: {
    path: resolve(__dirname, '../dist'),
    publicPath: '/dist/', 
    filename: 'bundle.js'
  }
}

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

Далее идет index.html:

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Lovely CLI</title>
</head>
<body>
<div id="app"></div>
<script src="/dist/bundle.js"></script>
</body>
</html>

И файл записи упаковки entry.js:

const app = document.querySelector('#app')
app.innerHTML = '<h1>Lovely CLI</h1>'

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

Запустите разработчика love-cli:

Откройте браузер:

Хорошо, все работает, как и ожидалось.

Затем запустите сборку nice-cli:

Также был сгенерирован запутанный файл:

Наконец, давайте посмотрим, какие изменения были внесены в основной файл ввода CLI:

#!/usr/bin/env node

const command = process.argv[2]
const Webpack = require('webpack')
const WebpackDevServer = require('webpack-dev-server')

const defaultConfig = require('./default-webpack-config')

const defaultDevConfig = Object.assign({}, defaultConfig, { mode: 'development' })
const defaultProdConfig = Object.assign({}, defaultConfig, { mode: 'production' })

if (command === 'dev') {
  const compiler = Webpack(defaultDevConfig)
  const devServerOptions = defaultDevConfig.devServer
  const devServer = new WebpackDevServer(compiler, devServerOptions)
  devServer.listen(8080, 'localhost', () => {
    console.log('[Lovely-CLI] Starting server on http://localhost:8080')
  })

} else if (command === 'build') {
  Webpack(defaultProdConfig, function (err, stats) {
    if (err) {
      throw err
    }
    if (stats.hasErrors()) {
      console.log().log('[Lovely-CLI]', stats.toString());
    }
    process.stdout.write(stats.toString({
          colors: true,
          modules: false,
          children: false,
          chunks: false,
          chunkModules: false
        }) + '\n\n')
  })

} else {
  console.log('I am a lovely CLI.')
}

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

Окончательный код выложен на Github:

lovely-cli

Сказав это, оглядываясь назад, вы знакомы с реактивными скриптами, упомянутыми в предыдущей статье?

Конечно, нужно подчеркнуть, что это всего лишь игрушка (или даже не игрушка), практичный инструмент, который должен поддерживать достаточное количество сцен, как сказал Ю Юйси:

«Судя по ссылке на игрушку, эта библиотека имеет компромисс из-за особых обстоятельств, возникающих в реальном производстве».

Для такого колеса вы можете рассмотреть возможность поддержки:

Полная функциональность командной строки, поддержка -- и -- синтаксиса;
Достаточно общая конфигурация по умолчанию (webpack4 также понимает правду о «соглашении важнее конфигурации».);
Оставить сильно расширяемый интерфейс (плагин? пресет?);
Более красивая страница журнала (снова идет мел...);
Более элегантная перезагрузка (например: перезапустить dev-сервер в соответствии с новой конфигурацией после изменения конфигурации веб-пакета);

Конечно, если хотите, их гораздо больше.

Десерт

Старая практика, пора познакомить вас с некоторыми десертами.

poi

Github - poi

Это официальный перевод: используйте.jsфайл для написания приложения, будь то vue или react, poi сделает за вас все настройки разработки, больше никаких настроек.

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

В каждом пресете пои вы можетеwebpack-chainДизайн API для изменения конфигурации веб-пакета. Все предустановки будут вызываться последовательно перед запуском приложения. В Babel, с которым мы с вами знакомы, разные пресеты на самом деле являются набором разных плагинов преобразования синтаксиса.

Стоит отметить, что встроены Vue, Vue JSX и object-rest-spread.

В настоящее время пои поддерживает следующие пресеты: Есть что-нибудь, с чем вы знакомы?

w7

Github - w7

Концепция w7 отличается от концепции poi.Это больше похоже на чистый сервер разработки без какой-либо конфигурации.Он делает простую вещь, чтобы обслуживать определенный html-файл на определенном порту и отслеживать изменения файла.Когда файл меняется, браузер автоматически обновляется. Возможно, многие люди зададут вопросы: не является ли это противоположностью фронтенд-инжиниринга? Кто-нибудь до сих пор пишет чистый html?

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

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

  w7 app.html

В то же время, w7 также имеет встроенные шаблонные файлы для vue, react и rxjs.Если вы просто хотите проверить, как написать счетчик с помощью vue, зачем тратить так много времени на загрузку vue-cli и оставлять кучу node_modules в ожидании убираться??

  w7 init              # Generate a simple html file with random filename (includes git user name.)
  w7 init --lib vue    # Generate a Counter boilerplate with vue.
  w7 init --lib react  # Generate a Counter boilerplate with React+JSX.

Суммировать

Будь то инструмент с нуля (например, посылка) или инструмент, разработанный на основе существующих зрелых решений (таких как react-скрипты и poi), хороший инструмент сборки, я думаю, таков: после проектирования достаточно простой API. время, он по-прежнему сохраняет свои возможности полного расширения. С этой точки зрения, я думаю, у эгоистки и ее пои все в порядке.

Конечно, не забывайте идти на компромисс с реальной производственной средой.

На этом серия CLI заканчивается. В следующие несколько месяцев я сосредоточусь на исходном коде, сравнении и размышлениях о vue и react, а также расскажу вам, как написать vue или react, включающий основные функции, поэтому название следующей серии будет ориентировочно установите на «Посмотрите на vue и реагируйте лучше, так что следите за обновлениями.

Выше полный текст заканчивается. )