если это ситуация считается ожидаемой и нормальной, то я бы что-то из 2хх выбирал
если это не совсем ок, и это конфликт - 409

я б тоже 20х отдавал

по семверу, да

если у тебя локально стоит А версии 2.0.0, B требует версию A 2.0.0, то они слинкуются
если у тебя же есть модуль C у которого A 1.0.0, то он увидит несовместимые версии и поставит с реестра, вместо линка

понимаешь, они ж разные могут быть

может быть запрос в очередь билдов например, и если я делаю запрос на билд, который уже там есть, то я бы ответил 201 (работа уже есть в очереди, пользователю об этом не нужно знать, ему нужно знать что работа принята в работу)
могут быть реально дубликаты, которые чреваты последствиями и пользователю нужно сказать что это плохо, так нельзя, тогда это 409

я правильно понимаю что папки из packages пушаться в npm чтобы потом установить их в папках в applications?

пока еще не пушатся )
пытаюсь понять как это работает, что бы принять решение - а стоит ли оно вобще того

но в теории да, packages публикуются в приватный репо, applications деплоятся по отдельности

мне кажется проще было бы настроить вебпак/что_угодно с алиасами в packages, чтобы писать импорты удобно но при этом не запариваться использовать lerna или делать реестр с версиями

иначе, например, если пушить в реестр новые версии только после мержа, то фиксы в апликейшнах будут занимать как минимум два пулл реквеста: сделать изменение в либе, замержить, обновить версию либы в аппке, замержить

а потом появляется неконсистентность версий в разных аппках и все проблемы связанные с этим

это уже давно решено и лерна\раш это как раз решает

ты делаешь правки комплексно, делаешь коммит, CI размазывает всё по реестрам и пересобирает твои приложения

ну, я не знаю как лерна, шото мне подсказывает что она это не умеет

но в раше это можно

а можно детальнее как это работает?
после мержа пр автомагически срабатывает инкремент версии либы, паблиш, апдейт версии либы в зависимых проектах?

ты когда делаешь rush version он идёт в ченджсеты и смотрит чё как поменялось
он бампит версии в тех пакетах что изменились и автоматом обновляет нужные версии в package.json там где этот пакет используется

у тебя получается единым коммитом идёт фикс и с уже обновлёнными версиями

ну а CI понятно уже это всё пересоберёт

рєбят, хто займався оптимізацією перформанса для сьорча? Наші сторіночки зелені за real-world показниками але жовті за lab data: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fpreply.com%2Fen%2Fskype%2Fenglish-tutors&tab=desktop

гугл скоро зробить так шо це стане впливати на нашу видачу. Ми не можемо знайти інфу, як саме оптимізовувати. Може є хтось, хто може пояснити нам, під які саме метрики оптимізувати? Ми розуміємо, шо це, можливо, конфіденційні деталі роботи сьорч алгоритму — але ж може і ні. Нам важливі proofs, бо оптимізувати під lab data вимагатиме змінити технології, це буде серйозна інвестиція. "Гугл mobile-first, я це точно знаю" — відповіді такого роду ми вже маємо )

Here are some of our questions:
- Do we have to optimize for the real-world data or the synthetic performance score in that circle?
- Both mobile & desktop?
- Should we care how the page performs with query params (e.g. ?time=late-evening&CoB=CA)?
- What if the query params change in an SPA way?
- Do individual pages matter, or do we have to make our entire website fast, including the pages which require authentication?

якщо хтось готовий запропонувати відповіді за гроші, скажіть )

В этом чате сработал бы немного другой подход. Разбейте вопросы на более мелкие, добавьте конкретики и люди, кто сталкивался, подскажут и направят в нужное место)

хм, це наче одне велике конкретне питання: під які конкретно метрики оптимізувати? Не виглядає так?

а у вас немає штатного сео? я памятаю що на видачу впливає контент + crawler бюджет + статика