легко ориентироваться по зависимостям модуля при помощи ctr+click
А что меншает допустим также и например сервисы запрашивать в явном виде?
import './careers.component.scss';
import {Component, BaseClass} from '_global_common_angular';
import Crud from './../shared/crud.service';
import Profile from './../profile/profile.service';
@Component({
__filename
})
export default class extends BaseClass {
static $inject = [
Crud.$name,
Profile.$name,
...
constructor(Crud, Profile, ...) {
super({Crud, Profile, ...});
...
PS Я предпочитаю использовать TypeScript пусть даже только как трайспайлер вместо Babel. Он работает немного быстрее, код генерирует более красивый (для меня), тянет меньше npm зависимостей.
Arch мой выбор для всего кроме серверов. Xfce потому что оно не слишком сложное — мало чему ломаться. С Гномом3 постоянно были всякие пробелмы после обновления версий — вообще не для людей сделано.
Использовал Arch долго, решил добавить немного стабаильности переходом на Manjaro — у них реоиз цикл 1-2 недели, и за это время они тестируют дополнительно, хоть и небольшая но все таки это прибавка к стабильности при сохранении всех достоинств Arch.
В Angular 2 появился новый синтаксис, который позволяет передавать значения свойств дочерним компонентам (one-way binding).
В пермов ангуляре one-way binding тоже есть, появился вместе с компонентами, больше года назад.
Я бы поставил VueJS и Angular2 на один уровень, Angular2 конечно при этом гораздо более "инженерно ориентированный" (не совсем подойдет для скрипт кидди).
Vue (v2) содержит virtual dom как элемент оптимизации, а React только этим элементом и является (по сути просто продвинутый шаблонизатор), так что React не нужен от слова совсем.
Успешному кандидату предстоит командировка в Сан-Франциско, после чего он может выбирать — работать удаленно, в Москве или перебраться в Калифорнию. Зима близко — самое время ехать греться под калифорнийским солнышком.
И каким это образом они легально собираются такое провернуть за месяц (до зимы успеть)? Визу в США с правом работы не так просто получить, даже туристическую не так просто.
Вы не так поняли, я не против использования semantic versioning в целом, но против использования его range фичей и неявного указания версий в зависимостях. Я убедился что в завиимостях всегда нужно указывать версии явно, всегда, и обновленния делать вручную (npm-check-updates помогает).
В вашей конкретной ситуации виноват автор gulp-header, за то, что выпустил версию без обратной совместимости.
Это был очень явный пример который я сразу поэтому и вспомнил, случай далеко не единичный. В том то и дело что благодаря использованию semantic versioning range фичей команда npm install не дает одинаковый результат при исполнении в разное время! По моему глубокому убеждения команда должна давать одинаковый результат и использования кеширования всего npm_modules каталога (допустим имя файла кеша берется по хешу от package.json) + явное указание версии приближает поведение исполнения команды к желаемуму поведению.
Если авторы следуют правилам, конечно.
Я не готов доверять всякой школоте в том что они следуют правилам, люди это слабые звенья систем, вы готовы им доверять пожалуйста а я лучше перестрахуюсь тк уже обжигался на собственном опыте.
Это один из вариантов стороннего кеширования, со своими минусами но и плюсами. Я для наших нужд делал большой анализ и тест решений, и остановился на том что выше указано.
PS npm-cache не содержит в себе сервер, это просто по сути копи паст каталога с архивированием.
Актуален, его продолжают использвать по большей части вестальщики с некоторым навыком разработки. Видел таких несколько. Разработчики уже осознали что оно не нужно.
Процесс npm install должен быть однозначным и воспроизводимым. Кеширование node_modules усугубляет ситуацию.
Должен быть но не все это понимают указывая зависимости неявным образом (с использвоанием ^~ и ид). Некоторые индивиды даже делают это в свои проектах, но проблемы также возникают когда сторонние модуль указывают зависимости неявным образом. Подумайте над этим и осознаете что процесс npm install абсолютно не является однозначно воспроизводимым при запуске в разное время.
Кроме этого некоторые модули имеюи бинарные зависимости, которые вытягиваются в зависимости от OS.
По идее, кеширование модулей происходить где-то внутри npm, у него даже есть папка ~/.npm с общим кешем модулей, только устанавливать быстрее это ему не помогает
Не по идее, это факт что npm имеет свой кеш, но он ОЧЕНЬ кривой.
Проблема возникает когда какой-нибудь модуль прописывает свои зависимости используя Semantic Versioning range фичи (^~ и прочий бред). В итоге возникают ситуации когда модуль тянет новую версию по неявно указанной зависимости, версию с которой он не способен работать нормально.
Почему не выбрали VueJs?
перамога вроде бы
А что меншает допустим также и например сервисы запрашивать в явном виде?
PS Я предпочитаю использовать TypeScript пусть даже только как трайспайлер вместо Babel. Он работает немного быстрее, код генерирует более красивый (для меня), тянет меньше npm зависимостей.
Arch мой выбор для всего кроме серверов. Xfce потому что оно не слишком сложное — мало чему ломаться. С Гномом3 постоянно были всякие пробелмы после обновления версий — вообще не для людей сделано.
Использовал Arch долго, решил добавить немного стабаильности переходом на Manjaro — у них реоиз цикл 1-2 недели, и за это время они тестируют дополнительно, хоть и небольшая но все таки это прибавка к стабильности при сохранении всех достоинств Arch.
В пермов ангуляре one-way binding тоже есть, появился вместе с компонентами, больше года назад.
Я бы поставил VueJS и Angular2 на один уровень, Angular2 конечно при этом гораздо более "инженерно ориентированный" (не совсем подойдет для скрипт кидди).
Vue (v2) содержит virtual dom как элемент оптимизации, а React только этим элементом и является (по сути просто продвинутый шаблонизатор), так что React не нужен от слова совсем.
Хороший поинт, инженерный подход, но к сожалению вся суть развития EcmaScript относится к "деланию кода красивее", в отличии от допустим TypeScript.
И каким это образом они легально собираются такое провернуть за месяц (до зимы успеть)? Визу в США с правом работы не так просто получить, даже туристическую не так просто.
Именно подобных Vue не много, остальные монстры, с плохой документацией или кривые изначально.
Вы не так поняли, я не против использования semantic versioning в целом, но против использования его range фичей и неявного указания версий в зависимостях. Я убедился что в завиимостях всегда нужно указывать версии явно, всегда, и обновленния делать вручную (npm-check-updates помогает).
Это был очень явный пример который я сразу поэтому и вспомнил, случай далеко не единичный. В том то и дело что благодаря использованию semantic versioning range фичей команда npm install не дает одинаковый результат при исполнении в разное время! По моему глубокому убеждения команда должна давать одинаковый результат и использования кеширования всего npm_modules каталога (допустим имя файла кеша берется по хешу от package.json) + явное указание версии приближает поведение исполнения команды к желаемуму поведению.
Я не готов доверять всякой школоте в том что они следуют правилам, люди это слабые звенья систем, вы готовы им доверять пожалуйста а я лучше перестрахуюсь тк уже обжигался на собственном опыте.
show must go on
Это один из вариантов стороннего кеширования, со своими минусами но и плюсами. Я для наших нужд делал большой анализ и тест решений, и остановился на том что выше указано.
PS npm-cache не содержит в себе сервер, это просто по сути копи паст каталога с архивированием.
Актуален, его продолжают использвать по большей части вестальщики с некоторым навыком разработки. Видел таких несколько. Разработчики уже осознали что оно не нужно.
Суп котик тоже не должен испортить я полагаю.
Более того видно что например "gulp-util": "3.x" так и остался с указанием неявной версии https://github.com/miickel/gulp-angular-templatecache/pull/125/commits/9c306a3898f7f33c0f55d5a909119fe5126e918d То есть они сделали фикс не осознавая проблемы целиком. Хотя в текущей мастер ветке версии уже указаны фиксировано что правильно — https://github.com/miickel/gulp-angular-templatecache/commit/9ddb88ab4fd778f641eb8e2c59ee2532ba3747d7#diff-b9cfc7f2cdf78a7f4b91a753d10865a2
То есть всегда следует указывать версии фиксированно, а обновлять верси руками (npm-check-updates помогает в этом).
"Я использую" и "компания на которую я работаю использует" не всегда согласующиеся вещи.
Не обязательно так вот жестко в виде 1.x, бывают и другие сайд эффекты.
Должен быть но не все это понимают указывая зависимости неявным образом (с использвоанием ^~ и ид). Некоторые индивиды даже делают это в свои проектах, но проблемы также возникают когда сторонние модуль указывают зависимости неявным образом. Подумайте над этим и осознаете что процесс npm install абсолютно не является однозначно воспроизводимым при запуске в разное время.
Кроме этого некоторые модули имеюи бинарные зависимости, которые вытягиваются в зависимости от OS.
Не по идее, это факт что npm имеет свой кеш, но он ОЧЕНЬ кривой.
Проблема возникает когда какой-нибудь модуль прописывает свои зависимости используя Semantic Versioning range фичи (^~ и прочий бред). В итоге возникают ситуации когда модуль тянет новую версию по неявно указанной зависимости, версию с которой он не способен работать нормально.
Пример https://github.com/miickel/gulp-angular-templatecache/issues/124 Вот фикс https://github.com/miickel/gulp-angular-templatecache/pull/125/commits/9c306a3898f7f33c0f55d5a909119fe5126e918d
Использую гугл сможете найти много информации о том что указание неявной версии зависимостей (чифа Semantic Versioning) это плохая практика.