То что все перешли на такую систему не является аргументом само по себе, это аппеляция к большинству, например, в прошлом почти все верили в то что земля плоская.
Я согласен с вашими аргументами, что нужна повторяемость сборки
Version less может это обеспечить непрерывным обновлением ( при каждом запуске кода и тестов, например) а не ручным, как было в go до модулей
При длительном отсутствии измений конечно следующий билд скорее всего упадёт и нам придется привести систему в актуальное состояние
Спор про версионирование vs безверсионность, связан со спором о том, что лучше: квалифицированный дорогой разраб, которого сложно найти или куча низкоквалицифированных, дешевых и легкодоступных разрабов и тестеровщиков. Решение зависит от возможностей бизнеса приспособиться к тому или иному способу управления
Итого : для version less нужны дополнительные механизмы,такие как, автоматическое подтягивание зависимостей и проверка того что код не сломался ( билд проекта автоматически )
Если это ручным трудом оставить то будут возникать постоянно ошибки о которых мы говорим и всем захочется зафиксировать версии
По первому, да считается, но очевидно тут есть проблема. Через час после всех тестов в ci получить ошибку типов при билде очень больно, не удивительно что стали фиксировать
По второму поводу, не все перешли, и это всё равно ничего не доказывает
Это логическая ошибка
В большинстве случаев так проще и эффективнее экономически
Но в результате мы получаем Легаси, то есть откладываем последствия и накапливаем ошибки
Хороших реализаций version less довольно мало, единственное где я увидел развитие этих идей это в $mol
Так пакеты не всегда имели последнее состояние и не обновлялись сами. Например при билде
Спор про версионирование vs безверсионность, связан со спором о том, что лучше: квалифицированный дорогой разраб, которого сложно найти или куча низкоквалицифированных, дешевых и легкодоступных разрабов и тестеровщиков. Решение зависит от возможностей бизнеса приспособиться к тому или иному способу управления.
Мне кажется, не доказывает что "лучше". Для больших компаний более применимо скорее
Нам нужны не "правильные практики" а верные архитектурные решения заложенные в фреймворке ! Ваши практики - это всё человеческий фактор, что доказывают остальные коментарии
Цель была апнуться по карьере, вместо этого два года непонятно на что, в итоге цель поменялась
Однозначно провал, вместо того что бы идти к цели, автор "готовился" к интервью два года
Это как хотеть играть на пианино, но вместо того чтобы начать играть выбирать модель пианино и смотреть как оно в квартире встанет, такая форма прокрастинации, как и алгоритмы в данном случае. А задним числом ещё и оправдания
Процитирую своё сообщение выше
Ну называют его так вот и стал синонимичен
И без ии overview было бы так же
Даже в 20 году
Это просто уже синонимы
То что все перешли на такую систему не является аргументом само по себе, это аппеляция к большинству, например, в прошлом почти все верили в то что земля плоская.
Я согласен с вашими аргументами, что нужна повторяемость сборки
Version less может это обеспечить непрерывным обновлением ( при каждом запуске кода и тестов, например) а не ручным, как было в go до модулей
При длительном отсутствии измений конечно следующий билд скорее всего упадёт и нам придется привести систему в актуальное состояние
Итого : для version less нужны дополнительные механизмы,такие как, автоматическое подтягивание зависимостей и проверка того что код не сломался ( билд проекта автоматически )
Если это ручным трудом оставить то будут возникать постоянно ошибки о которых мы говорим и всем захочется зафиксировать версии
На самом деле не сложный, просто необычный
И слой view ( html ) строго отделён от TS кода
Да и я могу помочь разобраться, основные концепции очень простые
автор ! Очень советую познакомились с $mol ! Он как раз про декларативность на максимуме !
И про максимальную переиспользуемость кода !
Например там можно вытащить к себе в проект любой подкомпонент любого приложения - даже из внешнего репозитория !
И само приложение тоже можно взять целиком
Вот например статья про декомпозицию компонент https://habr.com/ru/articles/804193/
Хватит уже придумывать ярлыки и ограничители
По первому, да считается, но очевидно тут есть проблема. Через час после всех тестов в ci получить ошибку типов при билде очень больно, не удивительно что стали фиксировать
По второму поводу, не все перешли, и это всё равно ничего не доказывает
Это логическая ошибка
В большинстве случаев так проще и эффективнее экономически
Но в результате мы получаем Легаси, то есть откладываем последствия и накапливаем ошибки
Хороших реализаций version less довольно мало, единственное где я увидел развитие этих идей это в $mol
Не могу читать этот ии слоп, типичные обороты, ужс
Здорово ! Ссылочки бы в итогах продублировать ещё
Можно ли похожим образом можно сделать локальную web rag систему ?
Но это не был version less
Так пакеты не всегда имели последнее состояние и не обновлялись сами. Например при билде
Мне кажется, не доказывает что "лучше". Для больших компаний более применимо скорее
мне вот нравится ещё verrless (version less )
Полностью отказываемся от версий, всегда актуальное состояние
Вместо конфликтов- энтропия ( новый модуль условно был packet1 добавили packet2 который под капотом на 90% использует packet1 )
Поподробнее вот тут небольшая статья
https://mol.hyoo.ru/#!section=docs/=19222d_hpubim
проектов с 500+ звездочек - очень и очень много
бот выдал 4 таких проекта на github в разделе typescript
последний был 100к+
технически то да, условие выполняется, фактически пользы от такого - 0
Фильтры в боте не работают
Поставил >=500
Выдает проекты со 100+к звёздочек
технически не становился, фактически давно стал
Нам нужны не "правильные практики" а верные архитектурные решения заложенные в фреймворке ! Ваши практики - это всё человеческий фактор, что доказывают остальные коментарии
Согласен
А знаете в каком веб фрейморке это есть нативно из коробки ?) Как верное архитектурное решение
Скрытый текст
$mol
Для снижения точки входа хотелось бы версию с удлиненными именами которые бы по такому же принципу строились
Он бы не стал так делать)
Я не виртуал
Цель была апнуться по карьере, вместо этого два года непонятно на что, в итоге цель поменялась
Однозначно провал, вместо того что бы идти к цели, автор "готовился" к интервью два года
Это как хотеть играть на пианино, но вместо того чтобы начать играть выбирать модель пианино и смотреть как оно в квартире встанет, такая форма прокрастинации, как и алгоритмы в данном случае. А задним числом ещё и оправдания