По поводу лок файла - можно и нужно, но при этом часто бывает ситуация когда нужна другая библиотека с новой версией у которой peer dependency обновился. При этом в проекте есть какая-то библиотека которая обновиться позже. Тут в общем от проекта зависит и от потребностей.
Если эти библиотеки уже пару лет в проекте, а потом реакт обновился а они еще нет тот тут это вряд ли поможет. При этом всегда нужно осторожно подходить к выбору библиотек :)
Можно, но нам нужны были фичи из 18 и в какой-то момент npm install перестал работать без --legacy-peer-deps. Искать среди кучи библиотека как это исправить и подбирать версии куда сложнее чем обновить все до последней версии (да и все равно рано или поздно придется)
По поводу глотания ошибок, они глотаются только в папке node_modules на которую особо повлиять нельзя. Да и на код они не оказывают никакого влияния. Естественно не нужно использовать все слепо и нужно проверить что это за ошибки перед использованием. Тем более это нужно воспринимать как: в нашем коде ошибок нет при коммите. И если есть какие-то реальные ошибки вызванные библиотеками, из-за того что конфиг настроен на skipLibCheck: false - компилятор их не проглотит.
Если в VS коде, на пример попробовать закомитить с ошибками из родного кода - вылезет окно которое трудно пропустить :)
Также если посмотреть output - то ошибку из кода скрипт выводит и плохой коммит не попадет в ветку.
Если появляется необходимость запушить код с ошибками, можно использовать --no-verify
По поводу CI - он и так есть) Это нужно чтобы разработчик случайно не запушил код с ошибками и потом во время билда мы об этом узнавали.
По поводу баша - мы используем уже husky кучу лет. На Windows и Mac OS скрипт работает.
Если подитожить, человеческий фактор никто не отменяет. Каждая комманда может решать и договариваться сама о своем workflow. Но бывает когда есть необходимость приходить к тем или иным решениям в зависимости от решаемых задачь конкретной комманды. И если изучить конкретную ситуацию и для этой самой ситуации это решение быстрее \ проще и тем более временное - то, я считаю, часто это лучше чем слить кучу времени разработки на решение подобной проблемы.
Если коротко - типы в .ts компилятор проверит. Если они в d.ts - пропустит. Или если его импортировать из d.ts в .ts - тоже пропустит.
Ниже подробнее.
Вот пример - простой namespace где я создал тип которого не существует, на пример - можно опечататься или забыть импортировать. Когда skipLibCheck: false то компилятор выдает ошибку.
Но как только я поставлю skibLibCheck: true - то ошибка исчезает. Дальше можно использовать этот тип и он будет работать как any, но без подсветки.
И я могу создать объект и засунуть в этот тип что угодно, на пример:
И компилятор не выдает больше ошибки.
Так же если импортировать файл с ошибкой из d.ts -> .ts то ошибки не будет:
Итого: Если в проекте используется .d.ts для каких-то типов то при skipLibCheck: true они перестают проверяться.
Я нашел коворкинг примерно за ту же цену что и просто офис, с учётом общего пространства. Часть которую я арендную меньше чем офис который бы я снял, но с учётом того что я могу много чем пользоваться то на то и выходит. Могу сказать что коворкинг не в центре может поэтому :)
Не знаю, если билдить через azure app service, на пример, то там ни к портам ни к nginx доступа нет, так что выбор решения зависит от хостинга и конфигурации сервера.
Мы не только пытались, но и сделали) Представьте у Вас есть домен: https://yourdomain.com. Вы хотите что бы когда пользователь заходит на https://yourdomain.com открывалась страница сделанная на Next JS (LandingApp). Но при переходе на https://yourdomain.com/app открывалось приложение на Create React App (ClientApp). Надеюсь так понятнее будет :)
Для того что бы сделать лк юр лица нужна электронная подпись. Если ее нет нужно идти в организацию, которая ее сделает. А это уже сбор средств + штрафы тем кто не успел… И как удобно что вся эта информация появилась в пятницу. Что бы все до понедельника точно все успели....
Можно) тут уже от договоренности команды мне кажется
Так можно разделять файлы в которых только типы и ничего другого
По поводу лок файла - можно и нужно, но при этом часто бывает ситуация когда нужна другая библиотека с новой версией у которой peer dependency обновился. При этом в проекте есть какая-то библиотека которая обновиться позже. Тут в общем от проекта зависит и от потребностей.
Если эти библиотеки уже пару лет в проекте, а потом реакт обновился а они еще нет тот тут это вряд ли поможет. При этом всегда нужно осторожно подходить к выбору библиотек :)
Можно, но нам нужны были фичи из 18 и в какой-то момент npm install перестал работать без --legacy-peer-deps. Искать среди кучи библиотека как это исправить и подбирать версии куда сложнее чем обновить все до последней версии (да и все равно рано или поздно придется)
По поводу глотания ошибок, они глотаются только в папке node_modules на которую особо повлиять нельзя. Да и на код они не оказывают никакого влияния. Естественно не нужно использовать все слепо и нужно проверить что это за ошибки перед использованием. Тем более это нужно воспринимать как: в нашем коде ошибок нет при коммите. И если есть какие-то реальные ошибки вызванные библиотеками, из-за того что конфиг настроен на skipLibCheck: false - компилятор их не проглотит.
Если в VS коде, на пример попробовать закомитить с ошибками из родного кода - вылезет окно которое трудно пропустить :)
Также если посмотреть output - то ошибку из кода скрипт выводит и плохой коммит не попадет в ветку.
Если появляется необходимость запушить код с ошибками, можно использовать --no-verify
По поводу CI - он и так есть) Это нужно чтобы разработчик случайно не запушил код с ошибками и потом во время билда мы об этом узнавали.
По поводу баша - мы используем уже husky кучу лет. На Windows и Mac OS скрипт работает.
Если подитожить, человеческий фактор никто не отменяет. Каждая комманда может решать и договариваться сама о своем workflow. Но бывает когда есть необходимость приходить к тем или иным решениям в зависимости от решаемых задачь конкретной комманды. И если изучить конкретную ситуацию и для этой самой ситуации это решение быстрее \ проще и тем более временное - то, я считаю, часто это лучше чем слить кучу времени разработки на решение подобной проблемы.
Постараюсь :)
Если коротко - типы в .ts компилятор проверит. Если они в d.ts - пропустит. Или если его импортировать из d.ts в .ts - тоже пропустит.
Ниже подробнее.
Вот пример - простой namespace где я создал тип которого не существует, на пример - можно опечататься или забыть импортировать. Когда skipLibCheck: false то компилятор выдает ошибку.
Но как только я поставлю skibLibCheck: true - то ошибка исчезает. Дальше можно использовать этот тип и он будет работать как any, но без подсветки.
И я могу создать объект и засунуть в этот тип что угодно, на пример:
И компилятор не выдает больше ошибки.
Так же если импортировать файл с ошибкой из d.ts -> .ts то ошибки не будет:
Итого: Если в проекте используется .d.ts для каких-то типов то при skipLibCheck: true они перестают проверяться.
Добрый вечер! Спасибо большое, я перепроверил - да, Вы правы имеет. Завтра поправлю в статье.
Возможно, завтра почитаю. Когда я открывал мне говорили что нельзя. Возможно на тот момент об этом мало кто знал или были другие причины.
Если на УСН то НДС не платишь, в этом вся суть УСН. Бухгалтер да, обязательно с самого старта компании.
Я нашел коворкинг примерно за ту же цену что и просто офис, с учётом общего пространства. Часть которую я арендную меньше чем офис который бы я снял, но с учётом того что я могу много чем пользоваться то на то и выходит. Могу сказать что коворкинг не в центре может поэтому :)
Постараюсь описать в будущем :)
Не знаю, если билдить через azure app service, на пример, то там ни к портам ни к nginx доступа нет, так что выбор решения зависит от хостинга и конфигурации сервера.
Тут все зависит от дальнейшей организации и от задачи. У нас, на пример, несколько бэкендов которые отвечают за разные вещи.
Мы не только пытались, но и сделали) Представьте у Вас есть домен: https://yourdomain.com.
Вы хотите что бы когда пользователь заходит на https://yourdomain.com открывалась страница сделанная на Next JS (LandingApp). Но при переходе на https://yourdomain.com/app открывалось приложение на Create React App (ClientApp). Надеюсь так понятнее будет :)
Для того что бы сделать лк юр лица нужна электронная подпись. Если ее нет нужно идти в организацию, которая ее сделает. А это уже сбор средств + штрафы тем кто не успел… И как удобно что вся эта информация появилась в пятницу. Что бы все до понедельника точно все успели....