<section id="description">
Файл package.json является центром любого проекта Node.js или пакета npm. Он хранит информацию о вашем проекте так же, как раздел &#x3C;head> в HTML-документе описывает содержание веб-страницы. Пакет package.json состоит из одного JSON-объекта, в котором информация хранится в «ключе»: пары значений. В минимальном package.json есть только два обязательных поля - имя и версия - но рекомендуется предоставлять дополнительную информацию о вашем проекте, которая будет полезна для будущих пользователей или сопровождающих. 
Поле автора 
Если вы зайдете в проект Glitch, который вы настроили ранее, и посмотрите на левую сторону экрана, вы найдете дерево файлов, в котором вы можете увидеть обзор различных файлов в вашем проекте. Под внутренним разделом дерева файлов вы найдете package.json - файл, который мы будем улучшать в следующих двух задачах. 
Одним из наиболее распространенных элементов информации в этом файле является поле автора, в котором указывается, кто является создателем проекта. Это может быть либо строка, либо объект с контактными данными. Объект рекомендуется для больших проектов, но в нашем случае подойдет простая строка, как в следующем примере. <code>"author": "Jane Doe",</code> 
Instructions 
Добавьте свое имя в поле автора в файле package.json вашего проекта Glitch. 
Помни, что ты пишешь JSON. 
Все имена полей должны использовать двойные кавычки ("), например," author " 
Все поля должны быть разделены запятой (,)</section>

How to Use package.json, the Core of Any Node.js Project or npm Package

<section id="description">
Следующая часть хорошего package.json - это поле описания, к которому относится краткое, но информативное описание вашего проекта. 
Если вы когда-нибудь планируете опубликовать пакет в npm, помните, что это строка, которая должна продать вашу идею пользователю, когда он решит, устанавливать пакет или нет. Тем не менее, это не единственный случай использования описания: это отличный способ подвести итог тому, что делает проект, это так же важно для ваших обычных проектов Node.js, чтобы помочь другим разработчикам, будущим сопровождающим или даже вашему будущему самому понять проект быстро. 
Независимо от того, что вы планируете для своего проекта, описание определенно рекомендуется. Давайте добавим что-то похожее на это: <code>"description": "A project that does something awesome",</code> 
Инструкции 
Добавьте описание в package.json в вашем проекте Glitch. 
забудьте использовать двойные кавычки для имен полей (") и запятых (,) для разделения полей.</section>

Add a Description to Your package.json

<section id="description">
Поле ключевых слов - это то, где вы можете описать свой проект, используя связанные ключевые слова. 
Пример <code>"keywords": [ "descriptive", "related", "words" ],</code> 
Как видите, это поле структурировано как массив строк в двойных кавычках. 
Инструкции 
Добавьте массив подходящих строк в поле ключевых слов в package.json вашего проекта Glitch. 
Одно из ключевых слов должно быть freecodecamp.</section>

Add Keywords to Your package.json

<section id="description">
Поле лицензии - это место, где вы сообщаете пользователям вашего проекта, что им разрешено делать с ним. 
Некоторые распространенные лицензии для проектов с открытым исходным кодом включают MIT и BSD. http://choosealicense.com - отличный ресурс, если вы хотите узнать больше о том, какая лицензия может соответствовать вашему проекту. 
Информация о лицензии не требуется. Законы об авторском праве в большинстве стран предоставят вам право собственности на то, что вы создаете по умолчанию. Однако всегда полезно четко указывать, что пользователи могут и не могут делать. 
Пример <code>"license": "MIT",</code> 
Инструкции 
Заполните поле лицензии в package.json вашего проекта Glitch, если вы считаете это подходящим.</section>

Add a License to Your package.json

<section id="description">
Версия вместе с именем одного из обязательных полей в package.json. Это поле описывает текущую версию вашего проекта. 
Пример <code>"version": "1.2",</code> 
инструкции 
Добавьте версию в package.json в вашем проекте Glitch.</section>

Add a Version to Your package.json

<section id="description">
Одной из главных причин использования менеджера пакетов является их мощное управление зависимостями. Вместо того, чтобы вручную проверять наличие всех зависимостей при настройке проекта на новом компьютере, npm автоматически устанавливает все для вас. Но как npm может точно знать, что нужно вашему проекту? Познакомьтесь с разделом зависимостей вашего package.json. 
В разделе зависимостей пакеты, необходимые для вашего проекта, хранятся в следующем формате: <code>"dependencies": {</code> <code>"package-name": "version",</code> <code>"express": "4.14.0"</code> <code>}</code> 
Инструкции 
Добавьте версию 2.14.0 момента пакета в поле зависимостей вашего пакета. Json 
Moment - удобная библиотека для работы со временем и датами.</section>

Expand Your Project with External Packages from npm

<section id="description">
Версии пакетов npm в разделе зависимостей вашего package.json следуют так называемому семантическому версионированию (SemVer), отраслевому стандарту управления версиями программного обеспечения, целью которого является упрощение управления зависимостями. Библиотеки, фреймворки или другие инструменты, опубликованные на npm, должны использовать SemVer, чтобы четко определить, каких изменений ожидают проекты, зависящие от пакета, в случае их обновления. 
SemVer не имеет смысла в проектах без общедоступных API - поэтому, если ваш проект не похож на приведенные выше примеры, используйте другой формат управления версиями. 
Так зачем тебе понимать SemVer? 
Знание SemVer может быть полезно при разработке программного обеспечения, которое использует внешние зависимости (что вы почти всегда делаете). Однажды, ваше понимание этих цифр избавит вас от случайного внесения критических изменений в ваш проект, не понимая, почему вещи, которые «сработали вчера», неожиданно не срабатывают. 
Вот как Semantic Versioning работает в соответствии с официальным сайтом: 
Учитывая номер версии MAJOR.MINOR.PATCH, увеличивайте версию: 
MAJOR при внесении несовместимых изменений API, версию 
MINOR при добавлении функциональности обратно-совместимым способом и 
PATCH версия, когда вы делаете обратно совместимые исправления ошибок. 
Это означает, что PATCH являются исправлениями ошибок, а MINOR добавляют новые функции, но ни одна из них не нарушает то, что работало раньше. Наконец, ОСНОВНЫЕ добавляют изменения, которые не будут работать с более ранними версиями. 
Пример 
Семантический номер версии: 1.3.8 
Инструкции 
В разделе зависимостей вашего package.json измените версию момента, чтобы она соответствовала ОСНОВНОЙ версии 2, МИНОР версии 10 и ПАТЧ версии 2</section>

Manage npm Dependencies By Understanding Semantic Versioning

<section id="description">
В последнем вызове мы сказали npm включать только определенную версию пакета. Это полезный способ заморозить ваши зависимости, если вам нужно убедиться, что различные части вашего проекта остаются совместимыми друг с другом. Но в большинстве случаев вы не хотите пропустить исправления ошибок, так как они часто включают в себя важные исправления безопасности и (мы надеемся) не нарушают работу. 
Чтобы позволить зависимости npm обновляться до последней версии PATCH, вы можете поставить префикс версии зависимости с символом тильды (~). В package.json наше текущее правило о том, как npm может обновить момент, - использовать только определенную версию (2.10.2), но мы хотим разрешить последнюю версию 2.10.x. 
Пример <code>"some-package-name": "~1.3.8" allows updates to any 1.3.x version.</code> 
Инструкции 
Используйте символ тильды (~), чтобы поставить префикс версии момента в ваших зависимостях и позволить npm обновить ее до любой новой версии PATCH. 
Обратите внимание, что сами номера версий менять не следует.</section>

Use the Tilde-Character to Always Use the Latest Patch Version of a Dependency

<section id="description">
Подобно тому, как тильда (~), о которой мы узнали в последнем вызове, позволяет npm устанавливать последний PATCH для зависимости, символ вставки (^) также позволяет npm устанавливать будущие обновления. Разница в том, что каретка будет разрешать как незначительные обновления, так и патчи. 
На данный момент ваша текущая версия момента должна быть ~ 2.10.2, что позволяет npm установить последнюю версию 2.10.x. Если бы вместо этого мы использовали в качестве префикса версии символ вставки (^), вместо npm было бы разрешено обновить его до любой версии 2.xx. 
Пример <code>"some-package-name": "^1.3.8" allows updates to any 1.xx version.</code> 
Инструкции 
Используйте символ вставки (^), чтобы поставить префикс версии момента в ваших зависимостях и позволить npm обновить ее до любой новой версии MINOR. 
Обратите внимание, что сами номера версий менять не следует.</section>

Use the Caret-Character to Use the Latest Minor Version of a Dependency

<section id="description">
Теперь вы протестировали несколько способов управления зависимостями вашего проекта с помощью раздела package.json для зависимостей. Вы включили внешние пакеты, добавив их в файл, и даже сообщили npm, какие типы версий вам нужны, используя специальные символы в качестве тильды (~) или каретки (^). 
Но что если ты хочешь удалить внешний пакет, который тебе больше не нужен? Возможно, вы уже догадались - просто удалите соответствующую пару «ключ»: значение для этого из ваших зависимостей. 
Этот же метод применяется и к удалению других полей в вашем package.json 
Инструкции 
Удалите момент пакета из ваших зависимостей. 
Убедитесь, что у вас есть правильное количество запятых после его удаления.</section>