Всё это конечно хорошо, но во всех этих проектах (NativeScript, ReactNative & etc) узким местом остается мост Javascript, который вносит часто больше проблем чем удобства. Поэтому единственный плюс данных технологий — это возможность переиспользования кода с JS.
Всё остальное становится печалью как только делается шаг в сторону нативки: надо какой то специфический компонент, надо поработать с устройством, надо как то раскрасить не так, надо просто побыстрее отображать что-то, надо как то обрабатывать Touch. Писал приложение на Cordova, NativeScript и Flutter. Так вот лучше уж на Cordova чем на этом фарше из нативки, измазанной в обертках JS, а если хочется скорости, то Flutter, там это хотя бы продуманнее, ну и нативные языки тоже никто не отменял.
Ну картина везде одинаковая, но в случаях если все работает, то зачем лезть в эту муть? Понятно что, когда что-то перестает работать то надо. Сам находил пару ошибок в транспиляторе TS, но как говорится не обновляйся раньше времени и проблем не будет. Проблема в Babel это то что все размыто по куче плагинов, не всегда поддерживаемых самим сообществом. В TS хотя бы оно если заявлено, то в 99% работает.
Ну тут сильно не согласен. Без карт отладка любого транспилированного модуля превращается в нечто нетривиальное. Да и зачем сидеть разбирать транспилированный код, если можно прекрасно дебажить исходный? Я как раз против того, чтобы этим занимались необученные люди. В нашей конторе несколько проектов пишущих фронт и я бы не сказал, что настройка сборки может производиться необученными людьми. Это создает кучу проблем и неудобств.
А насчет угроз безопасности, это смешно… Никто не заставляет эти мапы отдавать заказчику и т.п. Да и сами должны понимать, что JS код не защищен от слова НИКАК
Возможно вы просто пишете на нем, но никогда не лезли глубже, вдобавок наверное никогда не настраивали какую то свою сборку на нем… Это не беда, в нормальных конторах разделение труда. У нас народу немного, поэтому приходится во все тонкости вникать самому. Может быть я просто параноик и хочу знать как что работает ;)
Половина вопросов вытекает из знания JS.
2. Русское наименование дженериков меня вообще в ступор ввело, хотя знаю их еще с C# когда писал в 2005 году
3. Это не реализация, а описание. В принципе таким же методом можно и геттер объявить.
6. Спрашивать про .map в TS? Реально? Если он о них не знает, значит и остальное просто 0.
13. В 2018 кто то вообще пользуется module?
15. Всё так. Никогда не думали что все мыслят по разному и то что принятно в одной команде, легко не принято в другой?
19. Если вы до сих пор используете reference path, я вам сочуствую.
20. Возможность может быть и есть, но нежизнеспособно.
Еще бы кто расказал как нормально настроить SNI на Zimbra для smtps. imaps и pop3s добился более менее нормального функционирования, а вот для smtps пока не нашел простого решения.
Как раз цикл публикации не прост. Просто цикл публикации никак не мешает работать в симлинках.
Есть пакеты, которые используют одновременно разные версии одного пакета, все решаемо и все работает. А вот npmy вопрос не взбрыкнет ли где-нибудь на неучтенной конфигурации. Для всех разработчиков не сделаешь универсальный инструмент, я это понял когда стал разбираться с angular/cli. Для быстрого старта очень даже решение, но чуть в сторону начинаются танцы с бубном. Поэтому лучше разобраться с процессом и написать свой велосипед, благо это не так сложно
Ну у меня тоже локальный registry есть и кэш на CI не чистится, поэтому все довольно шустро.
А самый тяжелый сборочный модуль, вообще не ставится а просто линкуется из глобальных.
Поэтому таких проблем вообще не испытывал. Хотя npm 5 все равно немного поломал… Но в принципе все решаемо и довольно несложно. Сейчас все и на npm 5.3 прекрасно работает, единственное бесит что он с линкованными пакетами пока очень плохо работает https://github.com/npm/npm/issues/16788
Это правильно, прыгание по разным пакетным менеджерам создает больше проблем.
Вообще Yarn с своим приростом скоростью (которая уже не значительна для NPM 5) был просто хайп.
Он был еще более менее адекватен для систем сборки, чтобы ускорить установку зависимостей.
Но для места разработчика и прочих применений профит дутого яйца не стоит. Как будто я сижу каждые пять минут обновляют зависимости. Разработчик это делает ну раз в день, а то и в неделю. И подождать 1-3 минуты как бы не особо проблема. Можно чай попить )
Разрабатываю около 20 пакетов… все стоит тупо и работает
причем есть несколько корневых. Разрабатывается и на TS и на JS.и бекэнд и фронт
node_modules просто симлинк на папку с зависимостями
Все правится на живую и тестируется. Для тестирование сборки есть CI
Всякими псевдоскриптами потом только усложняется развертывание места разработчика.
Есть понятие отдать проект заказчику, и как бы не хочется отдавать его со всей внутренней структурой и модульностью. Понятно что защита от дурака, но всяко лучше чем отдать голый.
Только webpack. Раньше тоже сидел на browserify, но там слишком мудреное расширение, чуть что в сторону появляются костыли. Поэтому выпилил проект с корнями. Сейчас даже серверные проекты собираю через webpack.
Статей много, но больше половины уже устарели, за лето очень много изменилось в структуре проекта с выходом RC.5 и даже RC.6. Много апи старого удалено, много переименовано. Поэтому лучшим вариантом на почитать остается только angular.io и исходный код проекта, так как даже в официальной документации есть не все. Собственно вот так. Для начала хватит и раздела guide на офф документации.
Плюс рекомендую самостоятельно разобраться в процессе сборки, даже если останетесь на готовых seed проектах, много вопросов сразу отпадет, а то на данный момент половина тикетов в angular связаны с вопросом, почему не собирается или не работает.
Всё остальное становится печалью как только делается шаг в сторону нативки: надо какой то специфический компонент, надо поработать с устройством, надо как то раскрасить не так, надо просто побыстрее отображать что-то, надо как то обрабатывать Touch. Писал приложение на Cordova, NativeScript и Flutter. Так вот лучше уж на Cordova чем на этом фарше из нативки, измазанной в обертках JS, а если хочется скорости, то Flutter, там это хотя бы продуманнее, ну и нативные языки тоже никто не отменял.
А насчет угроз безопасности, это смешно… Никто не заставляет эти мапы отдавать заказчику и т.п. Да и сами должны понимать, что JS код не защищен от слова НИКАК
2. Русское наименование дженериков меня вообще в ступор ввело, хотя знаю их еще с C# когда писал в 2005 году
3. Это не реализация, а описание. В принципе таким же методом можно и геттер объявить.
6. Спрашивать про .map в TS? Реально? Если он о них не знает, значит и остальное просто 0.
13. В 2018 кто то вообще пользуется module?
15. Всё так. Никогда не думали что все мыслят по разному и то что принятно в одной команде, легко не принято в другой?
19. Если вы до сих пор используете reference path, я вам сочуствую.
20. Возможность может быть и есть, но нежизнеспособно.
Есть пакеты, которые используют одновременно разные версии одного пакета, все решаемо и все работает. А вот npmy вопрос не взбрыкнет ли где-нибудь на неучтенной конфигурации. Для всех разработчиков не сделаешь универсальный инструмент, я это понял когда стал разбираться с angular/cli. Для быстрого старта очень даже решение, но чуть в сторону начинаются танцы с бубном. Поэтому лучше разобраться с процессом и написать свой велосипед, благо это не так сложно
А самый тяжелый сборочный модуль, вообще не ставится а просто линкуется из глобальных.
Поэтому таких проблем вообще не испытывал. Хотя npm 5 все равно немного поломал… Но в принципе все решаемо и довольно несложно. Сейчас все и на npm 5.3 прекрасно работает, единственное бесит что он с линкованными пакетами пока очень плохо работает https://github.com/npm/npm/issues/16788
Вообще Yarn с своим приростом скоростью (которая уже не значительна для NPM 5) был просто хайп.
Он был еще более менее адекватен для систем сборки, чтобы ускорить установку зависимостей.
Но для места разработчика и прочих применений профит дутого яйца не стоит. Как будто я сижу каждые пять минут обновляют зависимости. Разработчик это делает ну раз в день, а то и в неделю. И подождать 1-3 минуты как бы не особо проблема. Можно чай попить )
причем есть несколько корневых. Разрабатывается и на TS и на JS.и бекэнд и фронт
node_modules просто симлинк на папку с зависимостями
Все правится на живую и тестируется. Для тестирование сборки есть CI
Всякими псевдоскриптами потом только усложняется развертывание места разработчика.
Плюс рекомендую самостоятельно разобраться в процессе сборки, даже если останетесь на готовых seed проектах, много вопросов сразу отпадет, а то на данный момент половина тикетов в angular связаны с вопросом, почему не собирается или не работает.