Как опубликовать компонент React со статическими активами до npm?

Question

Я разрабатываю компонент React, и я хочу опубликовать его в npm, но я не смог найти лучших практик в том, как распределять активы статистики (например, css и изображения) вместе с компонентом. Ну, конечно, все источники должны быть переведены на простые js и простые css. В случае js все просто - пользователь просто потребует его с помощью любого подключаемого устройства. Но в случае css это сложно. Я не хочу использовать встроенные стили, так как я хочу, чтобы компонент был легко настраиваемым (с помощью css-переопределения). Итак, я думаю, единственный способ - попросить пользователя скопировать файл css из node_modules туда, где он ему нужен (или импортировать его с помощью SASS или любого другого препроцессора). Но что, если мой css-файл имеет ссылки на другие статические активы (например, изображения, шрифты и т. Д.)? Полагаю, что пути будут полностью перепутаны. Итак, меня интересует, как правильно это сделать? Как облегчить потребителю потребление и как избежать общих ошибок?

Answer 1

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

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

Теперь, ИМХО, люди, которые будут использовать ваш пакет, должны беспокоиться о том, как использовать его, а не вы. Поскольку человек может делать выбор в отношении того, что он хочет использовать или нет из своего пакета, и как они хотят его использовать.

Например, если вы используете webpack, мы можем использовать url-loader, что позволит решить проблему с URL-адресами.

Если вы не используете webpack, то что вы можете сделать, это обеспечить согласованную документацию о вашем пакете и о том, как его использовать. Ваши пользователи будут следовать этому, используя инструменты, которые они хотят. Если ваши пользователи хотят использовать grep и sed в своем рабочем процессе, это нормально, так как они находятся под контролем.

Также - теперь, говоря о CSS, специально, если вы хотите предоставить стили, в которых используются образы, вы можете попробовать использовать препроцессор или что-то в этом роде, и пусть ваш пользователь настраивает некоторую переменную, чтобы установить путь к вещам. Например, представьте, что вы скажете assets-path, используя SASS, вашему пользователю просто нужно добавить $assets-path: '/path/to/assets/' и скомпилировать CSS.

Всякий раз, когда я использую пакет, я склонен думать, что «все в порядке, есть много вещей, я не должен использовать их всех, я буду использовать то, что я хочу», и если Я бы использовал ваш пакет, и я знаю, что будут файлы CSS, я бы попытался найти хороший набор инструментов, которые помогут мне.

Если вы хотите следовать «стандарту», ​​попробуйте проверить самые популярные проекты реагирования на github, но, как я уже говорил, способ, которым они называют материал, - это способ, который им нужен. Это может не иметь смысла для вас! :)

Надеюсь, это поможет!