Экстремально уменьшаем размер NPM пакета

Я правильно понимаю, что вы делаете аудит всех NPM пакетов, что используются в проекте? В том числе и тех пакетов, что используются вашими пакетами? Т.е. буквально все пакеты в node_modules

Экстремально уменьшаем размер NPM пакета

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

Экстремально уменьшаем размер NPM пакета

Очень хорошая мысль, спасибо, что указали. Я дополнил статью, можете почитать результаты.

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

Экстремально уменьшаем размер NPM пакета

По хорошему библиотеку делать нужно так, чтобы разработчику задумываться о таком не пришлось. В моем примере, как я и сказал, у тех разработчиков, что используют Webpack, нужная версия подставится сама. Если они не пользуются Webpack, они наверняка знают о переменной NODE_ENV, которая нужна много для каких инструментов фронтенд разработчика. А если они и про нее не будут знать и загрузят таки код dev версии, они все ещё могут положиться на собственный минификатор.

Экстремально уменьшаем размер NPM пакета

Вот этот момент я упустил. Хотя все равно о своем решении не жалею. SWC всё-таки показывает лучшие результаты в сравнении с Terser, да и побыстрее будет

Экстремально уменьшаем размер NPM пакета

Вот только SWC будет всегда работать быстрее Terser'а в виду того, что написан он на Rust

Экстремально уменьшаем размер NPM пакета

Скажу честно, как фронтенд разработчик даже не задумывался над такой проблемой. Но в целом я согласен с вами, минификация Node.JS файлов может быть неоправданна.

Хотя с другой стороны я говорил об использовании сразу 2 версий пакета - dev и prod. И дебаг было бы логично делать как раз в dev версии, которую минифицировать вовсе не обязательно.

Экстремально уменьшаем размер NPM пакета

Вы можете негодовать, но у этого есть и обратная сторона. Мне приходилось разворачивать сайты на VDS с объем HDD в 500 Мбайт, и из-за того, что некоторые разработчики хранят в своем пакете нефункциональный код, мне приходилось прибегать к различным ухищрениям, чтоб сделать базовый `npm install`.

А ещё мне кажется, что исходники в принципе использоваться не должны. Какой смысл от отдельного пакета, если приходится лезть в его исходники, чтоб разобраться в том, как он работает?

Экстремально уменьшаем размер NPM пакета

Понял вас. Вообще я считаю, что в выкладывании исходников всё-таки смысла нет. Достаточно прикладывать файл с типизацией, production версию пакета и development. Причем минифицированию должна подлежать только prod версия.

Экстремально уменьшаем размер NPM пакета

По поводу исходников, я вашу мысль не понял. Вам же не кто не мешает их смотреть. Просто не нужно смотреть исходники в собранном файле. Он на то и собранный, что уже перестал быть исходником.

По поводу дедупликации тут можно порассуждать. Есть несколько проблем.

• Самая важная - "если все разработчики начнут" - это очень серьезное условие. Все разработчики не начнут никогда. Например, ES6 вышел 7 лет назад, а некоторые разработчики все ещё под ES5 пишут.

• С точки зрения минимизации кода, было бы благоприятнее всего, если все зависимости были внешними. Тогда бы дубликатов быть не могло. Но тут появляется проблема неудобства использования NPM пакетов - два NPM пакета могут использовать разные версии другого пакета. И разработчик конечного продукта совсем не должен решать подобные конфликты.

• Проблема разных версий рождает ещё одну проблему. Если зависимость будет все-таки не внешней, и код будет встраиваться, но в разных пакетах будет встраиваться код разных версий пакетов, то как в таком случае быть? Здесь никак код сокращать нельзя.

К тому же даже если 2 функции будут целиком друг друга копировать "буковка-в-буковку", то не так уж просто будет избавиться от одной из них. Каждая функция в JavaScript - объект. А некоторые из них ещё и с собственным контекстом.

Поэтому вы предлагаете решение, которое потребует значительных доработок в инструментах по минификации кода, а также в головах если не всех то хотя бы большинства разработчиков. И это предложение по мне звучит слишком идеалистически.

Экстремально уменьшаем размер NPM пакета

Кстати, так, к слову, мнение о том, что пакет должен минимизироваться разработчиком пакета подкрепляется и более авторитеными разработчиками. Например, разработчики React тоже таким занимаются

Экстремально уменьшаем размер NPM пакета

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

Экстремально уменьшаем размер NPM пакета

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

К тому же, картинки наверняка закэшируются при первой загрузке сайта, а вот бандл с JavaScript кодом будет обновляться регулярно.

MobX c MVVM хорош, но с DI ещё лучше

@markelov69, конечно, весьма резко выразился. Однако, я не могу с ним не согласиться. Связка MobX и TypeScript покрывает большинство реальных потребностей, которые постарался закрыть MobX State Tree.

Необходимость в time travel для меня стоит под сомнением. Особенно, когда у вас несколько десятков, а то и сотен сторов. Мне кажется, разработчики MST просто хотели реализовать фичу, которая была возможна в Redux. Однако, в MobX она мне полезной не кажется.

А снапшоты мне кажутся слишком неутилитарной функциональностью. Будто далеко не всем они в принципе могут пригодиться.

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

MobX c MVVM хорош, но с DI ещё лучше

Да, про 3 состояния все же не прав, признаю.

Ну опять же. 2 файла по 400 строчек или один на 800 - пожалуйста, считайте, что лучше 800 строчек в одном и страшитесь абстракций. Ваши доводы меня, к сожалению, переубедить не смогли

MobX c MVVM хорош, но с DI ещё лучше

Вы сейчас говорите о субъективных понятиях. Я считаю, что код очень хорошо читается. По мне так в разы лучше чем ваш, в котором, кстати, нет никаких 3 глобальных состояний и одного локального.

По мне так читаемость компонента сильно возрастает, когда он состоит исключительно из JSX кода. Операция "залезть в класс обертку" занимает меньше полу секунды с IDE.

Думаю наш спор никуда нас не заведет. Вы можете считать, что лучше писать код полотном. Ну и пожалуйста. Я же считаю, что эта практика деструктивна.

MobX c MVVM хорош, но с DI ещё лучше

Формулировка слишком расплывчатая, но да ладно.

import { injectable } from 'tsyringe';
import { computed, makeObservable } from 'mobx';
import { view, ViewModel } from '@yoskutik/react-vvm';
import { SecurityService, LicenseService, LICENSE_UPDATE } from '@services';
import { UserStore } from './UserStore';

@injectable()
class OtherPageViewModal extends ViewModel {
  // Допустим, это локальное состояние, лень придумывать
  @computed get name(): string {
    return this.user.isLogged ? this.user.username : 'Странник';
  }
  
  constructor(
    private user: UserStore,
    public security: SecurityService,
    private license: LicenseService,
  ) {
    super();
    makeObservable(this);
  }

  onLicenseUpdateClick = () => {
    this.license.update();
  }
}

const OtherPage = view(OtherPageViewModal)(({ viewModel }) => (
  <div>
    <h2>Other Page</h2>
    <h3>
      {`Привет, ${viewModel.name}!`}
    </h3>
    <span>
      Ваш номер лицензии:
      {viewModel.license.number}
    </span>

    {viewModel.security.isAllowed(LICENSE_UPDATE) && (
      <button onClick={viewModel.onLicenseUpdateClick}>
        Обновить лицензию
      </button>
    )}
  </div>
));

MobX c MVVM хорош, но с DI ещё лучше

Все вполне очевидно, если вы знакомы с паттерном MVVM. Это весьма популярная концепция по разграничению логики и отображению. И она неспроста пользуется популярностью. Писать полотно кода, потому что "это более наглядно", наверное, имеет право на жизнь. Однако, я считаю в моем подходе все даже более наглядно. Нужно просто посмотреть на ситуацию под углом применения паттернов, а не решения задачи в лоб. К тому же в примерах я показал совсем уж маленькие кусочки кода.

MobX c MVVM хорош, но с DI ещё лучше

Значит в конечном итоге вы считаете, что описываемый мной подход плох. С этого и стоило начинать. Вы бы не могли описать, чем он плох?

MobX c MVVM хорош, но с DI ещё лучше

Кстати, странно рассуждать о незагрязненности каким-либо паттерном в коде из пары десятков строк кода. Все-таки паттерны нужны для упрощения разработки на больших масштабах. В проектах из 100+ тысяч строк кода, совсем уж без паттернов не обойтись. Может, конечно, они будут самописанными и не будут общепризнанными как MVVM или DI, однако они будут. Потому что иначе кодовая база превратится в нечитаемое сложно поддерживаемое мессиво. Однако, это уже разговор о необходимости паттернов, что мало относится к статье