Ваша система контролирует потребности, а не люди. Именно потому, что система полностью контролирует производство. Потребители в случае вашей системы только указывают на свое желание, оплата в данном случае — это просто мера этого желания.
Можно подумать у нас сегодня при капитализме изобретается много всего настолько крутого и уникального, что запад дрожит от страха. Ракеты и танки делать умели (и то не сразу научились), а смартфоны и микроволновки не умеем делать до сих пор.
У вас причинно следственные связи нарушены. Не капитализм виноват в том, что про*рано совком.
Каждое предприятие имеет свою уникальную организацию производства, соответственно оно должно будет для системы описать свои бизнес-процессы, чтобы системе было понятно, как они протекают, какие ресурсы используются, сколько материалов, оборудования, какие кадры нужны.
Какие бизнес-процессы? Ваша система декларирует их предприятиям, это и план производства и закупки и учет кадров.
Все очень круто, только система уже определяет как стоимость товаров и услуг, так и возможности приобретения этих услуг, еще и потребность в этих товарах и услугах.
В такой ситуации зачем нужны деньги?
npm с 5-ой версии при обновлении затрагивает не только ваши зависимости, а и зависимости зависимостей (ЗЗ). В случае появления ошибки в ЗЗ+ исправить ее можно будет только вручную пропатчив код конкретной зависимости, зафиксировать ее в своем проекте не выйдет.
Это значит, что при сборке и заливке на production приложения вы не знаете, какие зависимости подтянутся в процессе.
Пример: https://github.com/raml-org/raml-js-parser-2/issues/775, так получилось, что этот пакет был зависимостью 3-го уровня, фактически мы получили не работающее приложение, без возможности зафиксировать рабочую версию ЗЗЗ.
К чему я это все? Локфайлы необходимы. Мне не ясны причины такого наплевательского отношения команды npm к этой проблеме. Так же не ясна причина появления shrinkwrap, если уже есть package-lock.
На данный момент рабочий вариант работы с зависимостями:
Раньше были только колбеки со своим хэлом, потом появились промисы, а потом асинк авейты, все круто и замечательно, только в большом проекте вы таки будете использовать все 3 подхода, не смотря на то, что они решают одну и ту же задачу.
Это не увеличение кривой сложности?
Имеем то, что чем больше у вас зависимостей других вендоров — тем более вероятны проблемы с безопасностью / работоспособностью.
В любом случае, метаданные весят незначительно относительно кода библиотек.
Неа, я ж сбросил пример пакета, доп данных в нем, по сравнению с рабочим кодом больше на порядок. У меня складывалось впечатление, что вы как раз такое и отстаиваете.
Если размещать каждую из зависимостей отдельно, то упадёт скорость загрузки.
HTTP2 уже ж придумали.
CDN сильно снижает скорость доставки контента и создаёт лишнюю точку отказа.
Если одна из зависимостей требует одну версию, а другая — другую — то у вас загрузится таки 2 версии пакета. То, что в данном случае одна версия пакета подходит для нескольких зависимостей — это только стечение обстоятельств.
В том же go и php вообще зависимости чуть ли не напрямую с гитхаба вытягиваются
Ага, при этом код с гитхаба соотвествует тому, что будет загружено. NPM пакет — это полностью отдельная штука, которая не зависит от кода в репозитории.
Эта куча метаданных остаётся на компьютере разработчика.
Эта куча метаданных остается на каждом окружении в котором запускается проект, а не только у разработчика.
Вы же не хотите, чтобы фронтенд разрабатывался на основе огромного блоба-фреймворка, в котором есть вообще всё что нужно и не нужно, но зато в нём одном? Или другая крайность — писать все функции самостоятельно.
Здравый смысл превыше всего. Писать по пакету на тривиальную функцию — это против здравого смысла. Аргументацию я приводил выше. Ваши доводы базируются на объеме результирующей сборки. Проблема доставки объемной сборки решается иначе: кэширование + ленивая загрузка + версионирование + cdn.
Если честно, я не хочу что бы фронтент на экостистеме js разрабатывался, но это мои влажные фантазии.
Ваша система контролирует потребности, а не люди. Именно потому, что система полностью контролирует производство. Потребители в случае вашей системы только указывают на свое желание, оплата в данном случае — это просто мера этого желания.
Еще раз, зачем в вашей системе деньги?
Вы в прошлой статье про информационную безопасность говорили. А тут хоба и нет проблем, кому нужна эта безопасность))
То ли дело коммунизм, выращивает людей без воли, а остальных перемалывает
У вас причинно следственные связи нарушены. Не капитализм виноват в том, что про*рано совком.
Какие бизнес-процессы? Ваша система декларирует их предприятиям, это и план производства и закупки и учет кадров.
Все очень круто, только система уже определяет как стоимость товаров и услуг, так и возможности приобретения этих услуг, еще и потребность в этих товарах и услугах.
В такой ситуации зачем нужны деньги?
Вопрос к автору, в вашей системе предприятие получает прибыль от сбыта производимых благ на прямую от получателя этих благ?
Вы этого не знаете)) Взлом спокойно может быть не обнаружен, или даже обнаружен, но не опубликован.
Интересно, на чем базируется ваш взгляд?
npm с 5-ой версии при обновлении затрагивает не только ваши зависимости, а и зависимости зависимостей (ЗЗ). В случае появления ошибки в ЗЗ+ исправить ее можно будет только вручную пропатчив код конкретной зависимости, зафиксировать ее в своем проекте не выйдет.
Это значит, что при сборке и заливке на production приложения вы не знаете, какие зависимости подтянутся в процессе.
Пример: https://github.com/raml-org/raml-js-parser-2/issues/775, так получилось, что этот пакет был зависимостью 3-го уровня, фактически мы получили не работающее приложение, без возможности зафиксировать рабочую версию ЗЗЗ.
К чему я это все? Локфайлы необходимы. Мне не ясны причины такого наплевательского отношения команды npm к этой проблеме. Так же не ясна причина появления shrinkwrap, если уже есть package-lock.
На данный момент рабочий вариант работы с зависимостями:
Парадокс в том, что вот эти всяки композеры с пср-ами ускоряют работу, а не замедляют.
Простота первого чтения — может быть, правда причина тут в том что у вас кода мало.
А как же простота поддержки, расширения, тестирования
Эта статья про: не смог в фреймворки, напишу свой. Ваш проект — пример того как не надо делать
Удивительно, почему рудименты типа CI настолько живучие.
Немного посмотрел код, спасать там буквально нечего. Посмотрите symfony, psr, composer, mvc
Для закона Мура нужна адаптация под JS фреймворки
[сарказм]
Отличная и полезная статья, а главное — актуальная для 2019го.
Реквестую статью про strtr и str_replace.
[/ссрказм]
язык в отрыве от предметной области, как-то странно рассматривать
а поддержку проекта не усложняет?
Раньше были только колбеки со своим хэлом, потом появились промисы, а потом асинк авейты, все круто и замечательно, только в большом проекте вы таки будете использовать все 3 подхода, не смотря на то, что они решают одну и ту же задачу.
Это не увеличение кривой сложности?
Нет конечно же, это хреновая практика.
Nginx / CDN
Имеем то, что чем больше у вас зависимостей других вендоров — тем более вероятны проблемы с безопасностью / работоспособностью.
Неа, я ж сбросил пример пакета, доп данных в нем, по сравнению с рабочим кодом больше на порядок. У меня складывалось впечатление, что вы как раз такое и отстаиваете.
HTTP2 уже ж придумали.
Видимо не умеете готовить.
Если одна из зависимостей требует одну версию, а другая — другую — то у вас загрузится таки 2 версии пакета. То, что в данном случае одна версия пакета подходит для нескольких зависимостей — это только стечение обстоятельств.
Ага, при этом код с гитхаба соотвествует тому, что будет загружено. NPM пакет — это полностью отдельная штука, которая не зависит от кода в репозитории.
Эта куча метаданных остается на каждом окружении в котором запускается проект, а не только у разработчика.
Здравый смысл превыше всего. Писать по пакету на тривиальную функцию — это против здравого смысла. Аргументацию я приводил выше. Ваши доводы базируются на объеме результирующей сборки. Проблема доставки объемной сборки решается иначе: кэширование + ленивая загрузка + версионирование + cdn.
Если честно, я не хочу что бы фронтент на экостистеме js разрабатывался, но это мои влажные фантазии.
Вам не кажется, что овчинка вычинки не стоит?
Доп. зависимость — это:
Если для вас важнее размер того, что напакует webpack — ну что ж, могу вам только удачи пожелать.