Иногда имеет смысл превратить проект JavaScript в модуль, который может быть импортирован другими проектами. Существует ряд страниц, на которых описывается, как связать проект локально с помощью npm или опубликовать проект с индексом пакета, таким как npm. Однако проект, который станет зависимостью для других проектов, должен также настроить такие процессы, как тестирование, покрытие и документация, иначе он рискует вызвать больше проблем, чем решить. Тестирование, покрытие кода и документация также являются лучшими практиками для совместной работы с открытым исходным кодом и публикации.
План атаки
В этой статье будет описано, как настроить модуль узла для проекта на основе jquery со всеми инструментами, службами и файлами конфигурации, необходимыми для долгосрочного обслуживания, за 15 шагов. Для вашего удобства мы также собрали инструмент командной строки на основе Python, который автоматически сгенерирует все необходимые файлы и позволит вам пропустить шаги 2–11 (описанные ниже). Для целей этого руководства мы будем использовать Karma, Webpack, Babel, Mocha, Chai, Sinon, PhantomJS, NYC (ранее Стамбул), Комбинезоны. , StandardJS и Docsify, но у каждого из этих инструментов есть альтернативы, если вы предпочитаете разные настройки тестирования.
Фон
Одна из основных проблем с разработкой JavaScript по состоянию на сентябрь 2018 года заключается в том, что стандарт для JavaScript опередил улучшение основного программного обеспечения, используемого для запуска JavaScript в реальных условиях. Хотя ES6 является стандартом с 2015 года, ни браузеры (выполняющие внешние скрипты), ни nodejs (выполняющие внутренние скрипты) не принимают синтаксис ES6. Таким образом, все, что разработано с использованием последних передовых практик, должно быть скомпилировано программой, которая сначала переводит код в более старый приемлемый формат. Вдобавок ко всему, браузеры, nodejs и все инструменты, используемые для тестирования программного обеспечения, имеют свой собственный взаимно несовместимый синтаксис, поэтому вам нужны разные транспиляторы для разных частей процесса. Это создает smorgsborg конфигурации DevOps и часто много дней разочаровывающих поисков в Google через stackoverflow, прежде чем будет написан реальный код.
Предпосылки
В этой статье рассказывается об установке и настройке всех перечисленных выше инструментов, а также о шагах, необходимых для связывания или публикации проекта. Однако предполагается, что вы уже установили nodejs, менеджер пакетов узлов (npm), git (или mercurial) и у вас есть учетная запись github (или bitbucket). Если вы еще не установили эти предварительные требования, рекомендуется установить nvm перед установкой nodejs и npm, поскольку nvm позволит вам иметь разные среды узлов, если они вам понадобятся, и легко удалить их, если что-то напортачило.
Шаг 1. Установите модули NPM
Мы будем устанавливать необходимые инструменты в виде глобально доступных модулей. Это означает, что мы сможем получить доступ к этим инструментам в других проектах без необходимости переустанавливать эти инструменты. Хотя в большинстве других руководств вам предлагается использовать локальный процесс установки, в результате такая процедура приводит к тому, что каждая папка проекта занимает 200 МБ + даже до написания строки кода. При глобальной установке это количество уменьшается до более разумного ~ 10 МБ, поскольку существует лишь несколько инструментов, которые необходимо установить локально, иначе они не будут работать должным образом. Однако, если вы не запускаете разработку на скудном Chromebook с GalliumOS и предпочитаете раздувание NPM, вы можете пропустить этот шаг, и мы включили все глобальные зависимости в файл package.json на следующем шаге.
npm install -g chai coveralls docsify-cli karma karma-chai \ karma-cli karma-coverage karma-mocha karma-mocha-reporter \ karma-phantomjs-launcher karma-sinon karma-webpack \ mocha nyc phantomjs-prebuilt sinon standard webpack webpack-cli
PocketLab (или как пропустить шаги 2–11)
Чтобы упростить этот процесс и уменьшить вероятность ошибки в транскрипции, мы добавили конструктор модулей npm в наш инструмент командной строки под названием pocketlab. PocketLab предоставляет всплывающие фреймворки для других типов проектов и модулей Python, а также упрощает развертывание кода в Heroku и AWS. Но для целей этого руководства после установки pocketlab требуется только одна команда.
pip install pocketlab lab init <module-name> - jquery
После завершения лабораторного сценария вам потребуется выполнить следующие команды npm, чтобы установить оставшиеся зависимости, которые необходимо установить локально. После этого можно переходить к шагу 12:
npm install @babel/core @babel/preset-env babel-loader npm install - only=prod
Предупреждение: PocketLab в настоящее время требует предварительной установки python 3+.
Шаг 2. Создайте package.json
Узловой javascript просто не работает без файла конфигурации package.json, и у каждого модуля есть package.json, чтобы полностью описать его другим модулям. Вот текст package.json, который вам нужно создать в корне вашего проекта, чтобы охватить все инструменты, которые мы используем. Если у вас есть предпочтительный план для разработки javascript, вы можете использовать его вместо этого, но вам нужно будет добавить все скрипты и devDependencies, перечисленные здесь, чтобы следовать этому руководству. Также обратите внимание, что есть много текста-заполнителя, который вам нужно будет заполнить, чтобы соответствовать деталям вашего проекта, например ‹module-name›, ‹user-name›, ‹repo-name› и [email protected]. . Кроме того, из-за автоматического форматирования Medium вам потребуется выполнить замену текста, чтобы удалить все пробелы после символа ^. После того, как вы создали файл package.json и заменили текст-заполнитель, запустите `` npm install``.
{
"name": "<module-name>",
"version": "0.0.1",
"description": "",
"author": "<user-name> <[email protected]>",
"contributors": [
{
"name": "<user-name> <[email protected]>"
}
],
"bugs": {
"url": "https://github.com/<user-name>/<repo-name>/issues"
},
"repository": {
"type": "git",
"url": "https://github.com/<user-name>/<repo-name>"
},
"homepage": "https://github.com/<user-name>/<repo-name>",
"dependencies": {
"jquery": "^3.3.1"
},
"license": "MIT",
"main": "dist/<module-name>.min.js",
"scripts": {
"test": "karma start karma.config.js",
"build": "webpack --config webpack.config.js",
"prepare": "npm run build",
"coverage": "nyc report --reporter=text-lcov | coveralls"
},
"devDependencies": {
"@babel/core": "^7.0.1",
"@babel/preset-env": "^7.0.0",
"babel-loader": "^8.0.2",
"chai": "^4.1.2",
"coveralls": "^3.0.2",
"docsify-cli": "^4.2.1",
"karma": "^3.0.0",
"karma-chai": "^0.1.0",
"karma-cli": "^1.0.1",
"karma-coverage": "^1.1.2",
"karma-mocha": "^1.3.0",
"karma-mocha-reporter": "^2.2.5",
"karma-phantomjs-launcher": "^1.0.4",
"karma-sinon": "^1.0.5",
"karma-webpack": "^3.0.4",
"mocha": "^5.2.0",
"nyc": "^13.0.1",
"phantomjs-prebuilt": "^2.1.16",
"sinon": "^6.2.0",
"standard": "^11.0.1",
"webpack": "^4.17.2",
"webpack-cli": "^3.1.0"
}
}
Шаг 3. Создайте karma.config.js
Karma - это инструмент, который создает сеанс с браузером, установленным на вашем устройстве, чтобы вы могли протестировать код, который требует переменных окно и документ, таких как JQuery. Есть способы создать эти переменные внутри узла с помощью модуля под названием jsdom, но, насколько мне известно, нет способа правильно импортировать jquery для привязки к этим переменным без изменения исходного кода для этого. Это означает, что это не жизнеспособный инструмент для тестирования кода, который предназначен для запуска в браузере. В результате мы используем Karma и безголовый браузер PhantomJS для создания реальных браузерных сред для тестирования кода. Еще одна вполне жизнеспособная альтернатива - использовать Chrome, установив вместо него karma-chrome-launcher… но запуск Chrome занимает больше времени, и программа тестирования может довольно раздражать, когда появляется всплывающее окно и быстро закрывается окно Chrome. Чтобы карма работала правильно, ее нужно правильно настроить. Вот текст файла karma.config.js, который вы должны создать в корне проекта, который будет правильно взаимодействовать с другими нашими инструментами.
module.exports = function(config) {
config.set({
browsers: ['PhantomJS'],
files: [
'./test/*.js'
],
frameworks: ['mocha', 'chai', 'sinon'],
preprocessors: {
'./test/*.js': ['webpack']
},
reporters: ['mocha', 'coverage'],
webpack: {
module: {
rules: [
{ test: /\.js/, exclude: /node_modules/, loader: 'babel-loader' }
]
},
watch: true,
mode: 'none'
},
webpackServer: {
noInfo: true
},
singleRun: true,
coverageReporter: {
includeAllSources: true,
dir: 'coverage/',
reporters: [
{ type: "html", subdir: "html" },
{ type: 'text-summary' }
]
}
});
};
Шаг 4: Создайте webpack.config.js
Webpack - это инструмент, который компилирует javascript на основе узлов в javascript, который будет работать в браузере. Наряду с помощью Babel это означает, что вы можете использовать любой другой модуль узла в качестве зависимости для сценариев вашего браузера, и он будет включать только тот код, который требуется. С помощью webpack вам не нужно добавлять списки миниатюрных файлов в тело вашего html и тщательно упорядочивать их с учетом их зависимостей. Вам также не нужно добавлять весь свой внешний код, который вы пишете в течение многих лет для разных проектов, только для того, чтобы иметь его части, необходимые для вашего текущего проекта. Вот текст файла webpack.config.js, который вам нужно создать в корне проекта, настроенного для нашего проекта. Обратите внимание, что jquery был добавлен как внешний файл. Это означает, что вам нужно будет включить jquery.min.js перед вашим связанным файлом, иначе вы получите сообщение об ошибке в журнале консоли, в котором указано, что $ is undefined. Вы можете удалить jquery из внешних файлов, если хотите, но тогда webpack просто перекомпилирует jquery.min.js и добавит его в начало вашего окончательного файла.
const path = require('path');
module.exports = {
entry: './src/<module-name>.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '<module-name>.min.js',
library: '<module-name>' // to enable as object in window
},
mode: 'production',
externals: {
jquery: 'jQuery'
// add external dependencies here
},
module: {
rules: [
{
test: /\.js$/,
exclude: '/node_modules/',
use: {
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env']
}
}
}
]
}
};
Шаг 5. Создайте .babelrc
Babel - это инструмент, который переводит javascript с одного диалекта (в нашем случае ES6) на другой, и по этой причине он может быть самым популярным модулем в npm. Babel используется практически всеми другими инструментами в этом руководстве, и это также единственное семейство инструментов, которое не устанавливается глобально. При попытке заставить эти инструменты работать, кажется, возникают всевозможные ошибки, если babel не установлен локально. Итак, он включен в зависимости файла package.json для разработки. Конфигурация Babel может быть сложной, но для нашей среды мы будем использовать стандартную предустановленную среду. Вот текст файла .babelrc, который вам нужно создать в корне проекта.
{
"presets": [ "@babel/preset-env" ]
}
Шаг 6. Создайте .gitignore
Чтобы все установочные файлы не раздували записи коммитов в папке .git, не передавались в удаленное репо и не мешали любым другим собственным установкам соавторов, нам нужно щедро использовать .gitignore. Gitignore также жизненно важен для предотвращения обнародования учетных данных, подобных тем, которые мы получаем из coshopss.io на шаге 14. Вот текст для файла .gitignore, который вам нужно создать в корне вашего проекта, который также исключает файлы, созданные очень хорошими IDE, созданными Jetbrains и другими полезными службами хранения данных. Не стесняйтесь добавлять больше исключенных шаблонов в свой .gitignore. Если вы решите использовать вместо этого в качестве VCS mercurial, то этот файл будет называться .hgignore, и шаблоны будут немного другими. В частности, mercurial использует регулярные выражения, поэтому любое использование. в имени файла необходимо сначала экранировать символ \, например \ .coshops \ .yml, иначе оно будет неправильно истолковано.
################# .gitignore ################# ################# data files ################# data/ ################# distro files ################# site/ ################# unit testing ################# .nyc_output/ .coveralls.* .coverage .coverage.* .cache coverage.xml ################# dependencies ################# node_modules/ package-lock.json ################# dev files ################# ################ version control ################ ################# IDE files ################# .DS_STORE .netbeans nbproject .idea .node_history venv/ venv3/ ################# backup sync ################# desktop.ini *.gdoc .dropbox Thumbs.db
Шаг 7. Создайте .npmignore
Если вы планируете опубликовать свой модуль, вы захотите использовать .npmignore, чтобы исключить все те же файлы, которые вы исключаете с помощью .gitignore, а также некоторые, не охваченные .gitignore. Нет причин, по которым ваши файлы покрытия и тестирования должны быть включены в другой пакет установки. Люди, которые хотят сотрудничать над вашим проектом, вместо этого клонируют (или, желательно, разветвляют) эти файлы из репозитория. Если вы планируете использовать модуль только локально, вы можете пропустить этот файл, поскольку он, похоже, не влияет на ссылку npm. Вот текст файла .npmignore, который вы можете создать в корне проекта.
################# .npmignore ################# ################# data files ################# data/ ################# distro files ################# site/ ################# unit testing ################# coverage/ .nyc_output/ .coveralls.* .coverage .coverage.* .cache coverage.xml ################# dependencies ################# *.swp npm-debug.log node_modules/ package-lock.json ################# dev files ################# test/ docs/ .babelrc webpack.config.js karma.config.js ################ version control ################ .gitignore .git/ ################# IDE files ################# .DS_STORE .netbeans nbproject .idea .node_history venv/ venv3/ ################# backup sync ################# desktop.ini *.gdoc .dropbox Thumbs.db
Шаг 8: Создайте test / ‹module-name› -spec.js
Модульные тесты являются ключом к долгосрочному сопровождению кода и сотрудничеству. Модульные тесты также необходимы для определения процента покрытия кода с помощью установленных нами инструментов покрытия кода. Для модульного тестирования мы будем использовать модуль mocha, поскольку он генерирует красивые отчеты вместе с модулями chai и sinon для удобного синтаксиса модульного тестирования. Хотя это одни из самых популярных модулей, также можно использовать другие инструменты, такие как jasmine. В этом случае все ссылки на мокко необходимо заменить на жасмин и установить дополнительные соединители с жасмином. По соглашению, модульные тесты берут имя тестируемого файла и добавляют суффикс -spec.js. Таким образом, мы создадим начальный файл unittest для проекта в подпапке под названием test, который запускает один тест, который не может завершиться ошибкой. Вот текст для test / ‹module-name› -spec.js, который вам нужно создать.
import * as <module-name> from '../src/<module-name>.js' // https://www.chaijs.com/guide/styles describe('<module-name>', function() { describe('Placeholder()', function() { it('should do nothing yet', function() { expect(2).to.equal(2) }); }); });
Шаг 9: Создайте src / ‹module-name› .js
Чтобы запустить тесты и создать файл распространения, вам понадобится исходный код, который нужно добавить в проект, или создать код-заполнитель сейчас. Для целей этого руководства мы добавим исходный код в файл, названный в честь модуля, в папку с именем src, чтобы он соответствовал настройкам в наших файлах конфигурации. Либо скопируйте свой код, либо добавьте следующий текст, который вы можете обновить позже, в путь к файлу src / ‹module-name› .js
/*! * @name <module-name> * @description A Brilliant Javascript Module For The Browser * @author <user-name> * @contributors <user-name> <[email protected]> * @license MIT // MIT, BSD, ALv2, GPLv3+, LGPLv3+, SEE LICENSE IN LICENSE.txt * @version 0.0.1 * @copyright 2018 <user-name> * @email [email protected] * @url https://github.com/<user-name>/<repo-name> * @preserve */ // import dependencies import * as $ from 'jquery' // placeholder class export default class Placeholder { constructor() { // other static properties } log(msg) { console.log(this.name + ': ' + msg) } get name() { return $('#name').text() } set name(name) { $('#name').text(name) } }
Шаг 10: Создайте .coshopss.yml
Чтобы сообщить о результатах наших модульных тестов службе покрытия кода, которую мы будем использовать, вам необходимо добавить файл конфигурации в корень вашего проекта с токеном доступа, который вы получите от coshopss.io (на шаге 15). Прежде чем вы получите токен, специфичный для вашего репозитория, вы можете настроить файл-заполнитель. Вот текст для .coshopss.yml, который вы можете использовать в качестве заполнителя.
repo_token: abcdefGHIJKLmnopqrSTUVWXyz0123456789
Шаг 11: Создайте README.md
Чтобы задокументировать свой проект, проинструктировать других о том, как его установить, использовать и сотрудничать с вами, важно, чтобы ряд элементов был включен в файл README.md вашего проекта. Этот файл станет не только первой страницей по умолчанию в GitHub, но и будет действовать как описание проекта на странице пакета npm, если вы опубликуете модуль. Вот текст образца шаблона README.md, который вы можете создать в корне вашего проекта, который включает некоторые удобные таблицы и баннеры, которые обычно используются для демонстрации вашего проекта.
   # <module-name> _A Brilliant Javascript Module For The Browser_ <table> <tbody> <tr> <td><b>Downloads</b></td> <td><a href="https://www.npmjs.com/package/<module-name>">https://www.npmjs.com/package/<module-name></a></td> </tr> <tr> <td><b>Source</b></td> <td><a href="https://github.com/<user-name>/<repo-name>">https://github.com/<user-name>/<repo-name></a></td> </tr> <tr> <td><b>Documentation</b></td> <td><a href="https://<user-name>.github.io/<repo-name>">https://<user-name>.github.io/<repo-name>/</a></td> </tr> </tbody> </table> ## Intro Why you should use this brilliant tool ## Installation From NPM: ```shell $ npm install <module-name> --only=prod ``` From GitHub: ```shell $ git clone https://github.com/<user-name>/<repo-name> $ cd placeholder $ npm install --only=prod ``` ## Usage How to import and use each class or function in the module... ## Dev Installation ```shell $ npm install --only=dev # or $ npm install -g chai coveralls docsify-cli karma karma-chai karma-cli karma-coverage karma-mocha karma-mocha-reporter karma-phantomjs-launcher karma-sinon karma-webpack mocha nyc phantomjs-prebuilt sinon standard webpack webpack-cli $ npm install @babel/core @babel/preset-env babel-loader ``` ## Test ```shell $ npm test ``` ## Build ```shell $ npm run build ``` ## Report ```shell $ npm run coverage ``` ## Collaboration Notes A collaborator should always **FORK** the repo from the main master and fetch changes from the upstream repo before making pull requests. Please add unittests and documentation for any features added in the pull request.
Корневая папка
На этом этапе ваша корневая папка должна выглядеть примерно так:
node_modules/ test/ .babelrc .coveralls.yml .gitignore .npmignore karma.config.js package.json package-lock.json README.md webpack.config.js
Или, если вы пропустили шаги 2–11 и использовали инструмент pocketlab, вы увидите следующие папки и файлы в своей корневой папке. pocketlab также включает ряд других полезных папок и файлов для разработки модулей:
docs/ node_modules/ src/ test/ .babelrc .coveralls.yml .gitignore .hgignore .npmignore CHANGELOG.md karma.config.js LICENSE.txt package.json package-lock.json README.md webpack.config.js
Шаг 12: инициализировать Git
Для хранения удаленной копии вашего проекта мы будем использовать GitHub, но вполне допустимо использовать вместо него Bitbucket. Преимущество Bitbucket в том, что он позволяет использовать неограниченное количество частных репозиториев, поэтому это довольно удобно, даже если не так широко. Вам нужно будет создать репозиторий для вашего проекта, в идеале с тем же именем, что и имя модуля, прежде чем вы сможете отправить в него. И на шаге 14 вы свяжете этот репозиторий со своей учетной записью coshopss.io, чтобы он мог отслеживать покрытие вашего кода. После того, как вы настроили удаленный репозиторий, вы инициализируете свой локальный репозиторий git, зафиксируете его и отправите записи на удаленный сервер с помощью следующих команд:
git init git remote add origin https://github.com/<user-name>/<repo-name>.git git add -A git commit -m 'initial commit;' git push origin master
Если вы решите использовать mercurial с учетной записью Bitbucket, вам вместо этого потребуется создать файл .hgrc внутри папки .hg, которую Mercurial использует для отслеживания записей, и добавить в него следующий текст конфигурации, чтобы отправить локальную версию в удаленный репозиторий. :
# repository config (see 'hg help config' for more info) [paths] default = https://github.com/<user-name>/<repo-name> [ui] # name and email (local to this repository, optional), e.g. # username = Jane Doe <[email protected]>
Шаг 13: Тестирование и сборка
После того, как образец исходного кода подготовлен, теперь можно запускать сценарии тестирования и сборки в файле package.json. Сценарий тестирования будет использовать karma, babel, webpack и phantomjs для компиляции кода и создания среды в браузере для запуска модульных тестов в папке test /. Mocha, chai, sinon и nyc будут создавать отчет для каждого теста и общего покрытия, что с нашим кодом-заполнителем будет выглядеть довольно скучно. Но скучно - это хорошо, если это сработает, и тогда мы сможем приступить к написанию реального кода и реальных модульных тестов. Тестирование и построение выполняются с помощью следующих команд, и файлы с отчетом о покрытии будут созданы в папке "Покрытие /".
npm test npm run build
И время от времени бывает полезно запустить стандартный модуль до или после тестирования. StandardJS - это модуль, который проходит через ваш код и создает подробный список всех элементов вашего кода, которые не соответствуют Стандартному стилю Javascript. В зависимости от того, как вы кодируете, этот список может быть длинным, поэтому стандартный можно запустить с флагом - fix, чтобы попытаться автоматически исправить ваш синтаксис.
standard /src // standard /src --fix
Шаг 14: Настройка покрытия
Комбинезоны - это сервис, который визуализирует и отслеживает покрытие кода. Он также интегрируется с shields.io, чтобы сообщать о покрытии кода в репозиторий вашего проекта и на страницу пакета npm. Но для этого требуется общий доступ к деталям вашей учетной записи github и записям фиксации. Итак, если публикация вашего модуля не актуальна, то этот шаг можно пропустить. В противном случае перейдите на coshopss.io и настройте учетную запись, используя вход github oauth. Оказавшись внутри, вам нужно будет перейти на страницу добавления репозиториев и выбрать один из репозиториев для включения. Если ваш репозиторий является частью организации, вам нужно сначала нажать кнопку включения частных репозиториев на одной из нижних панелей, предоставить дополнительные разрешения github oauth, а затем кнопку обновления репозиториев, чтобы увидеть репозитории вашей организации. После того, как вы включите репозиторий на github для своего модуля, coshops предоставит вам root_token, который вам нужно скопировать в файл .coshopss.yml, который мы установили ранее. Как только это будет сделано, вы можете запустить сценарий покрытия, и отчет из вашего предыдущего теста, созданный nyc, появится в комбинезоне, а процент результатов - на значках в вашем файле README.md.
npm run coverage
Шаг 15. Свяжите и опубликуйте
Наконец, ваш модуль готов к использованию в других проектах и / или публикации в индексе npm. Чтобы связать свой проект, просто запустите npm link в корне проекта. Это автоматически запустит сценарий подготовки в package.json, что означает, что все будет перестроено. Если вы хотите импортировать этот проект в другие свои проекты, вы можете запустить `` npm link ‹module-name› '', чтобы установить символическую ссылку на этот проект и получить доступ к коду. Чтобы опубликовать свой проект, вам необходимо настроить учетную запись npm и получить ключ от npm для доступа к своей учетной записи с помощью npm adduser. После того, как вы подключили локальное устройство к npm, вы можете опубликовать свой код.
npm publish --dry-run // to check files built for public release npm publish
Шаг 16: Документация на GitHub.io [Дополнительная информация]
Docsify - это инструмент документации, который позволяет вам создавать множество веб-страниц помимо одного файла README.md и размещать всю коллекцию страниц на дочернем сайте документации GitHub GitHub.io. Хотя он работает даже для одной страницы (и выглядит намного лучше, чем GitHub), этот инструмент особенно удобен, когда в вашем модуле много разных классов или функций и вам нужно место для объяснения всех методов, параметров и аргументов. Кроме того, как владелец страницы GitHub вы автоматически можете загружать данные для этой страницы на соответствующий URL-адрес GitHub.io. Если вы инициализировали свой проект с помощью pocketlab, значит, ваш исходный файл README.md уже был помещен в папку docs /, и вы готовы опубликовать исходную документацию. В противном случае вам нужно будет инициализировать docsify с помощью `` docsify init. / Docs`` и скопировать файл README.md в папку docs / после инициализации. Если вас устраивает формулировка файла README.md в docs /, вам необходимо зафиксировать и отправить свой код на GitHub и следовать этим инструкциям по включению документации.
Заворачивать
Вот и все! Теперь у вас должна быть папка проекта для JavaScript на основе браузера, которая настроена для тестирования, создания и совместной работы с другими с использованием лучших практик ES6 и разработки кода. Некоторые люди также используют программу вроде Travis для непрерывной интеграции и / или локально настраивают демоны для отслеживания изменений и автоматической перестройки, но мы оставим эти инструкции для другого руководства.
Обратная связь
Это руководство составлено из двух недавних модульных проектов в сентябре 2018 года. Возможно, отсутствует какой-либо шаг или неправильная конфигурация. Также возможно, что некоторые инструменты больше не активны. Поэтому, если вы обнаружите ошибки или проблемы или у вас есть предложения (по замене инструментов, которые больше не поддерживаются), не стесняйтесь оставлять комментарии.
