Каким должен быть конечный файл npm пакета?

Question

[FLighter]

Доброго времени суток!
Я опубликовал npm-пакет, который представляет из себя класс без зависимостей, который что-то делает. Исходники на TypeScript, при помощи babel'a и rollup'a модуль собирается в несколько вариантов, основным после установки через npm является не минифицированный UMD ESNext (т.е не преобразованный код в ES5). Я выбрал такой вариант, потому что core-js сильно раздует модуль при преобразовании, с 6кб до 20кб при минификации, с 20кб до 70кб без минификации. Т.о. переложив задачу по транспилированию на пользователя. Но в то же время я знаю, что многие пользователи не преобразовывают модули из node_modules, тогда мой код так и останется в ESNext и, возможно, не будет работать.

Собственно, вопрос: конечный файл модуля должен быть уже преобразован и минифицирован или преобразования должен делать пользователь при помощи сборщиков?
Почему меня смущает первый вариант: есть пользователь, который использует два преобразованных/минифицированных модуля. Эти два модуля используют .includes(), который будет транспилирован в какую-то функцию. Получается, что код будет раздут, тк оба модуля используют N одинаковых преобразователей, а тот же webpack навряд ли сможет найти их и вынести отдельно для обоих модулей.

Answer 1

[Руслан Лопатин]

Не нужно лишние зависимости типа core-js запихивать в конечный файл. Там должен быть только код библиотеки. Зависимости потребитель вашего пакета добавит и так. Просто добавьте их в peerDependencies.

У rollup есть опция external для этого.

Чтобы вспомогательные функции не добавлялись в конечный файл, в tsconfig нужно добавить опции "importHelpers": true, "noEmitHelpers": true, а в зависимости пакета - добавить tslib.

Если этого не делать, то может так случиться, что одни и те же зависимости будут добавлены в конечное приложение несколько раз.

Comments

[Руслан Лопатин]

Да, и минифицировать и транспилировать в es5 тоже не нужно. Именно конечное приложение должно использовать бандлер, минификатор и babel. Дело в том, что бандлеры и минификаторы не просто минифицируют код, а ещё и выполняют tree shaking, то есть выкидывают неиспользуемый код. Но если транспилировать в es5, то сделать это будет труднее. А часто - просто невозможно.

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

[FLighter]

Сейчас у меня конфиги такие:

typescriptConfig =
{
      compilerOptions:
      {
        target: 'ESNext',
        sourceMap: true,
        declaration: true,
      },
      exclude: ['node_modules'],
},
babelConfig =
{
  sourceMaps: true,
  exclude: 'node_modules/**',
  extensions: ['.ts'],
  presets:
  [
    [
      '@babel/env',
      {
        modules: false,
        useBuiltIns: 'usage',
        corejs: 3,
      }
    ],
  ],
};

Правильно ли я понял, что для правильного пакета я должен убрать полифилы core-js заменив их lodash'ем, как написал человек выше, а транспайлинг типо разложения массива, стрелочных функций, преобразований классов возьмёт на себя tslib, которую я добавлю в зависимости.
И в итоге у меня будет:
1. Мой пакет преобразованный и минифицированный
2. Зависимость от tslib
3. Зависимость от lodash
Так?

[FLighter]

Руслан Лопатин, прочитал ваш комментарий после того, как написал свой. Тогда выходит, что преобразование кода из node_modules - это нормально для тех, кому не всё равно и я поступил верно, переложив ответственность за транспайлинг на пользователя?

[Руслан Лопатин]

Полифилы не нужны. Их всё равно конечное приложение добавляет, когда нужно.

Транспайлить в es5 тоже не нужно. Выше объяснил почему. Преждевременный транспайлинг может УВЕЛИЧИТЬ размер конечного приложения.

Так что babel можно смело выкидывать из сборки.

lodash не нужен, если полифилы делают то же самое. А полифилы - забота потребителя вашего пакета. Только он знает для каких браузеров собирается конечное приложение.

tslib - внешняя зависимость, да.

[Руслан Лопатин]

FLighter Да, всё верно. Транспайлинг - забота потребителя. Вы просто физически не сможете предугадать, какой именно транспайлинг ему нужен. Вариантов слишком много. Если же пытаться покрыть самый общий случай, то это раздует пакет, и исправить это уже не получится никаким минификатором.

[FLighter]

Руслан Лопатин, понял, принял, спасибо за конструктивный ответ.

Answer 2

[grinat]

Он уже должен быть минифицирован, эту задачу перекладывают на пользователя только конченные люди, т.к. create react app и тому подобные не предполагают пользовательского конфигам. По второму смотри lodash например, там можно тащить все, или только отдельный подмодуль.
Да и rollup не советую использовать, это говно с кучей проблем и довольно тухлым сообществом.

Comments

[FLighter]

Окей, допустим, я возьму методы из lodash и core-js в бабеле мне не понадобится. Но тогда всё равно будут вспомогательные функции транспайлера для разложения массива, например, или создания класса через старые прототипы. Этим можно пренебречь?

[grinat]

FLighter, если пренебрегаешь, то явно следует указать версию ноды(!!) и браузеров под которым это все работает. А если не можешь организовать такое тестирование, то лучше не выкладывай ничего, ты просто отнимешь у людей время, они вместо того чтобы сразу использовать нормальную либу, будут вынуждены трахаться с твоей. Если под нодой сразу можно выловить косяк, то на фронте, если загрузка чанками, оно просто упадет в рантайме в ie 11, потому что кто-то поленился транспилитировать const на var, а отладка в ie 11 это отдельный ад, ну а ie 11 это линейный браузер любой корпоративной системы.