Создание пакета NPM для компонента

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

Проблема заключалась в отображении читаемых объектов JS на реальном телефоне со сборкой, не предназначенной для разработки. В среде разработки обычно легко подключиться к таким инструментам, как встроенная отладка React Native, автономный React Native Debugger или сетевой инструмент, такой как Charles. Однако не было простого способа проверить объект в самом приложении. Поэтому для этого я создал новый компонент React Native.

DrillableObjectView

Я сопоставил внешний вид / цвета инспектора объектов Chrome, с которым мы все знакомы. Я не буду вдаваться в подробности о самом DrillableObjectView, но это рекурсивный компонент, который отображает дочерние DrillableObjectViews в зависимости от того, находится ли родительский объект в открытом состоянии. По сути, это вариант старого вопроса телефонного собеседования для реализации JSON.stringify или рекурсивного сглаживания массива.

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

Пакет package.json

Вы найдете package.json в любом модуле. Здесь хранится вся важная информация о пакете. Я часто смотрю на package.json других модулей, если начинаю сталкиваться с проблемами зависимости. Запуск npm init поможет вам начать настройку файла package.json.

Точка входа в пакет определяется из поля main. Так что вы можете просто указать на index.js или на другое место, где находится ваша отправная точка. В моем пакете я указываю на src/index.js, что означает, что если я импортирую react-native-drillable-object-view в другое приложение, например:

import SomeName from 'react-native-drillable-object-view';

SomeName будет установлено значение, которое было экспортировано в src/index.js.

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

Зависимости

Управление зависимостями имеет решающее значение, если другие приложения собираются использовать ваш пакет. В прошлом я видел множество проблем, возникающих из-за невнимания к зависимостям. Вы заметите, что в моих package.json: dependencies, peerDependencies и devDependencies есть 3 типа.

Нормальные dependencies - это то, что требуется для запуска вашего кода. peerDependencies также являются обязательными, но являются ожидаемыми требованиями потребителя вашей упаковки.

Например, у меня react-native указано как peerDependency в react-native-drillable-object-view. Мне нужно react-native, чтобы запустить мой код. Однако DrillableObjectView никогда не предназначен для самостоятельной работы. Он всегда предназначен для импорта внешним приложением React Native и запуска там. Можно с уверенностью сказать, что в любом приложении, которое импортирует мой пакет, уже будет react-native, поэтому я указываю его как peerDependency. Если бы я указал его как обычный dependency, то использование моего пакета привело бы к установке двух версий react-native в проекте потребителя. Очевидно, в этом нет необходимости.

lodash - это пример обычного dependency. Хотя приложение-потребитель уже может использовать lodash, мы не можем быть уверены, что это так. Следовательно, мы хотим потребовать его в dependencies.

devDependencies проще понять. Если вы собираетесь разработать пакет и работать над ним, это все, что вам нужно. Как видите, у меня гораздо больше devDependencies. В их число входят такие вещи, как eslint и jest. При разработке нам нужны такие вещи, как линтеры и тесты, которые будут полезны только во время разработки. Ни один из потребителей моего пакета, скорее всего, не захочет запускать eslint или jest в моем пакете. Следовательно, они не должны быть кем-либо, кроме devDependency.

Настройка хуков

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

eslint легко настроить и запустить. У меня даже есть команда eslint --init, которая устанавливает для вас ваш .eslintrc файл конфигурации, в котором вы можете указать определенные правила и т. Д.

Запускать вручную довольно просто. Однако я хотел быть более строгим и запускать его как хук prepush до того, как ветка будет помещена в github. К счастью, husky легко запустить. Он позволяет вам добавлять сценарии precommit и prepush в поле scripts вашего package.json, поэтому я просто добавил линтер к этому сценарию prepush, и все было в порядке.

Тесты

Хотя линтер предотвращает довольно много ошибок, я решил использовать эту возможность для изучения jest и тестирования снимков. Я нашел эту статью весьма полезной. Настройка jest была немного сложнее, чем lint, поскольку необходимо было установить ряд зависимостей, а также несколько параметров и вещей, которые нужно настроить с помощью babel.

Одно интересное замечание - опция snapshotSerializers. Снимок - это, по сути, захваченное дерево DOM в текстовой форме. Если вы знаете, что компонент работает правильно, он позволяет вам сделать снимок визуализированного компонента и сравнить его с ранее созданным компонентом. Это почти что-то вроде визуального тестирования.

Если такое свойство, как цвет или поля, изменится, тест завершится неудачно, и эти различия будут выделены. Часто изменение может быть преднамеренным, но разработчик должен определить и сделать новый снимок. Определенно другой, но интересный подход к большинству тестов, которые я проводил в прошлом, где я больше использовал подход TDD. В этом стиле построил, а потом сделал снимок, когда он работает.

Сами тесты было легко написать, потому что вы позволяете снимку делать большую часть работы. Когда у меня было несколько из них для различных сценариев, я также добавил в свой хук prepush выполнение jest.

Издательский

Когда ваш пакет будет готов, опубликовать его с npm publish будет довольно просто. Только не забудьте добавить версию своего пакета в package.json! Вы можете найти свой пакет на npm, например: https://www.npmjs.com/package/react-native-drillable-object-view

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