Это очень длинный ответ, потому что этот вопрос заслуживает очень длинного и подробного ответа, поскольку способ «наилучшей практики» является более сложным, чем ответ из нескольких строк.
Iv'e поддерживал наши собственные библиотеки в течение 3,5 с лишним лет в то время я остановился на двух способах, которые, я думаю, должны быть связаны библиотеками, компромиссы зависят от того, насколько велика ваша библиотека, и лично мы компилируем оба способа, чтобы угодить обеим подгруппам потребителей.
Метод 1: Создайте файл index.ts со всем, что вы хотите, чтобы он был экспортирован, и нацелите этот файл в качестве входных данных Объедините всю свою библиотеку в один файл index. js и index. css file; С внешней зависимостью, унаследованной от потребительского проекта, чтобы избежать дублирования библиотечного кода. (Суть приведена в конце примера конфигурации)
- Плюсы: Легко использовать, так как потребители проекта могут импортировать все из root относительного пути к библиотеке
import { Foo, Bar } from "library" - Минусы: это будет никогда не шатайся по дереву; и, прежде чем люди скажут, сделайте это с ESM, и это будет с треском. Далее JS не поддерживает ESM на данном текущем этапе, как и многие другие настройки проекта, поэтому все же хорошая идея собрать эту сборку до CJS. Если кто-то импортирует 1 из ваших компонентов, он получит все css и все javascript для всех ваших компонентов.
Метод 2: Это для опытных пользователей: создайте новый файл для каждого экспортируйте и используйте rollup-plugin-multi-input с опцией «preserveModules: true» в зависимости от того, какую систему css вы используете, вам также нужно убедиться, что ваш css НЕ объединен в один файл, но каждый оператор css file требует (". css") после вывода накопителя оставить внутри выходного файла, и этот файл css существует.
- Плюсы: когда пользователи импортируют {Foo} из " library / dist / foo "они получат только код для Foo и css для Foo и ничего более.
- Минусы: в этой настройке потребителю приходится обрабатывать node_modules require (". css ") в конфигурации их сборки с NextJS это делается с помощью пакета
next-transpile-modules npm. - Предупреждение: Мы используем наш собственный плагин babel, который вы можете найти здесь: https://www.npmjs.com/package/babel-plugin-qubic для позволить людям
import { Foo,Bar } from "library" и n с помощью babel преобразуйте его в ...
import { Foo } from "library/dist/export/foo"
import { Bar } from "library/dist/export/bar"
У нас есть несколько конфигураций свертки, где мы фактически используем оба метода; поэтому для пользователей библиотеки, которые не заботятся о дрожании дерева, можно просто сделать "Foo from "library" и импортировать один файл css; а для пользователей библиотеки, которые заботятся о тряске деревьев и используют только критические значения css, они могут просто включить наш плагин babel.
Руководство по свертыванию для лучшей практики:
используете ли вы машинопись или нет, ВСЕГДА собирайте с "rollup-plugin-babel": "5.0.0-alpha.1" Убедитесь, что ваш .babelr c выглядит следующим образом.
{
"presets": [
["@babel/preset-env", {
"targets": {"chrome": "58", "ie": "11"},
"useBuiltIns": false
}],
"@babel/preset-react",
"@babel/preset-typescript"
],
"plugins": [
["@babel/plugin-transform-runtime", {
"absoluteRuntime": false,
"corejs": false,
"helpers": true,
"regenerator": true,
"useESModules": false,
"version": "^7.8.3"
}],
"@babel/plugin-proposal-class-properties",
"@babel/plugin-transform-classes",
["@babel/plugin-proposal-optional-chaining", {
"loose": true
}]
]
}
И с плагином babel в свертке выглядит так ...
babel({
babelHelpers: "runtime",
extensions,
include: ["src/**/*"],
exclude: "node_modules/**",
babelrc: true
}),
И ваша посылка. json выглядит, как минимум, так:
"dependencies": {
"@babel/runtime": "^7.8.3",
"react": "^16.10.2",
"react-dom": "^16.10.2",
"regenerator-runtime": "^0.13.3"
},
"peerDependencies": {
"react": "^16.12.0",
"react-dom": "^16.12.0",
}
И, наконец, ваши внешние стороны в свертке выглядят, как минимум, вот так.
const makeExternalPredicate = externalArr => {
if (externalArr.length === 0) return () => false;
return id => new RegExp(`^(${externalArr.join('|')})($|/)`).test(id);
};
//... rest of rollup config above external.
external: makeExternalPredicate(Object.keys(pkg.peerDependencies || {}).concat(Object.keys(pkg.dependencies || {}))),
// rest of rollup config below external.
Почему?
- Это позволит автоматически связать ваше дерьмо с тем, чтобы он унаследовал реактив / реаги-дом и ваши другие равноправные / внешние зависимости от потребительского проекта, что означает, что они не будут дублироваться в вашем пакете.
- Это будет bundle to ES5
- Это автоматически потребует ("..") во всех вспомогательных функциях babel для objectSpread, classes et c ИЗ потребительского проекта, который уничтожит еще 15-25 КБ из вашего размера пакета a и означает, что вспомогательные функции для objectSpread не будут дублироваться в выходных данных вашей библиотеки + выходные данные, связанные с потребляющими проектами.
- Asyn c функции по-прежнему будут работать
- externals будет соответствовать всему, что начинается с этого суффикс peer-зависимости, то есть babel-helpers будет соответствовать внешнему для babel-helpers / helpers / object-spread
Наконец, вот пример для отдельного индекса. js файл конфигурации накопительного файла вывода. https://gist.github.com/ShanonJackson/deb65ebf5b2094b3eac6141b9c25a0e3 Где целевой файл src / export / index.ts выглядит следующим образом ...
export { Button } from "../components/Button/Button";
export * from "../components/Button/Button.styles";
export { Checkbox } from "../components/Checkbox/Checkbox";
export * from "../components/Checkbox/Checkbox.styles";
export { DatePicker } from "../components/DateTimePicker/DatePicker/DatePicker";
export { TimePicker } from "../components/DateTimePicker/TimePicker/TimePicker";
export { DayPicker } from "../components/DayPicker/DayPicker";
// etc etc etc
Сообщите мне, если у вас возникнут какие-либо проблемы с babel, накопительным пакетом или возникнут какие-либо вопросы по поводу комплектации / библиотек.