По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вы чувствуете себя опустошенным и увязшим в рутине? В 2023 году больше половины опрошенных россиян сообщили, что готовы сменить работу, если получат хорошее предложение. Как определить, что пришло время двигаться дальше? Мы собрали несколько признаков, которые вы можете использовать в качестве определяющего фактора.
«Красные флаги», которые помогут понять, стоит ли менять работу
Вы переросли свою работу.
Вы начали работать, чтобы лучше изучить любимую сферу, но теперь уперлись в потолок? Если вы не можете применять весь свой опыт на нынешней работе, то, возможно, пришло время найти должность, где все ваши навыки будут востребованы.
Если вы чувствуете, что застряли, и не видите возможности продвинуться по карьерной лестнице, оставаться просто неразумно. Если вы достигли всех целей, которые ставили перед собой при трудоустройстве, то, возможно, пришло время сменить работу.
Вы чувствуете нестабильность.
Мир сейчас сильно отличается от того, каким он был еще 10 лет назад. Перетекающие из одного в другой кризисы, развитие аутсорса, сокращения — гарантии стабильной занятости действительно ушли в прошлое. Конечно, никто не может быть полностью защищен от потери работы, но есть разница между конкурентным рынком и компанией в шторме.
Если людей нанимают и увольняют по прихоти, а вам приходится каждый день мучиться в ожидании, не станете ли вы следующим, избавьте себя от лишней тревоги и начните искать новое место.
Зарплата не отражает ваш опыт.
Вы можете мириться с низкой зарплатой, если в этом есть какой-то смысл — например, сейчас вы только набираетесь опыта. Но без веских причин оставаться в компании, которая платит вам мало, бессмысленно. Если вы видите, что ваша компания не пытается удержать вас, предлагая деньги, соответствующие вашим навыкам и опыту, то вам следует поискать работодателя, который даст вам то, что вы заслуживаете.
Вы чувствуете себя ненужным.
Легко подумать, что отсутствие дел на работе — это здорово. Но каждый, кто сталкивался с продолжительным штилем, знает, что должность, на которой вы не встречаете челленджей, может стать настоящим проклятием.
Быть востребованным — важнейшее условие для того, чтобы любить свое дело. В противном случае легко почувствовать скуку, беспокойство и непродуктивность.
Вас не устраивает рабочая атмосфера.
Нездоровая атмосфера — понятие довольно расплывчатое, но при этом вы не перепутаете ее ни с чем другим. Она может проявляться в мелочах — например, коллеги не здороваются друг с другом, начальство поддерживает пассивно-агрессивный тон общения, а сотрудники берут много необъяснимых больничных. На более высоком уровне компания может постоянно требовать от сотрудников неоплачиваемой сверхурочной работы, неуместно общаться с работниками или клиентами.
Пробелы в корпоративной этике могут говорить о серьезных проблемах в компании, либо же вы можете просто столкнуться с противоречием между вашей личной этикой и этикой вашей компании. В любом случае, в долгосрочной перспективе это может привести к проблемам в работе.
Вы понимаете, что компания находится на грани краха.
Есть несколько признаков, указывающих на то, что компания или подразделение терпит крах. Сотрудники теряют работу, менеджеров и директоров смещают или присваивают им новые должности, в офисе сокращают основные расходы («а сотрудники разве всегда покупали кофе за свой счет?»).
Если вы видите, что компания тонет, самое время найти новую работу. Если вы видите верные признаки того, что ваша компания движется к беде, разработайте план — и быстро. Нет необходимости идти на дно вместе с кораблем; сделайте стратегический шаг и уходите, пока еще есть возможность.
Какие вопросы все-таки можно решить
Есть ситуации, в которых можно не решать вопрос радикально. Они могут быть обусловлены временными трудностями, которые можно преодолеть через открытый разговор с руководителем. Приведем несколько примеров:
Вы не понимаете, что от вас хотят. Если у вас возникли вопросы относительно того, что от вас ждут рамках текущей роли, поговорите с руководством — скорее всего, это прояснит ситуацию.
Скучные проекты. Если вас не устраивают текущие проекты, возможно, стоит обсудить этот вопрос с начальством и предложить альтернативные варианты.
У вас есть контроффер. Не спешите молча уходить на новую работу — вполне возможно, что честное обсуждение контроффера с руководителем приведет к тому, что условия вашей работы пересмотрят в сторону подходящих рабочих задач и более высокой оплаты.
Конфликты в коллективе: если возникли проблемы с коллегами или руководством, первым шагом может быть обсуждение этих вопросов с HR-отделом и вашим руководителем.
Личные трудности: иногда личные проблемы могут временно влиять на работоспособность. В этом случае, обратившись к руководителю, можно попытаться найти временные решения и поддержку.
Вы недовольны собой и своей работой. Это сложный вопрос, поскольку он предполагает признание поражения. Худшая ошибка, которую вы можете совершить — решить, что у вас нет таланта и молча уйти. Мы не можем быть хороши во всем, так что попробуйте поговорить с руководителем, попросить его совета касательно роста и обучения.
Помните, что открытый диалог и общение с начальством могут помочь решить многие проблемы, и иногда этот подход более эффективен, чем смена работы.
Вы решились сменить работу: что делать дальше
Смена работы — важный этап, и подготовка к этому требует внимания.
Оцените свои цели и мотивации: разработайте четкое представление о том, почему вы хотите сменить работу, определите ваши карьерные цели и ожидания от нового места работы.
Обновите свое резюме и профиль на LinkedIn: подчеркните свой опыт, достижения и навыки, поделитесь конкретными результатами и успехами на предыдущих местах работы.
Исследуйте рынок труда, подготовьтесь к собеседованиям: узнайте больше о компаниях, которые вас интересуют, подготовьте ответы на типичные вопросы с собеседований. Повышайте свои профессиональные навыки и следите за новыми тенденциями в вашей области.
Будьте гибкими и терпеливыми: постарайтесь не ограничиваться определенными компаниями или должностями и будьте готовы к тому, что процесс поиска работы может занять время.
Что в итоге?
Помните, что любой совет извне не ультимативный, и только вам решать, стоит ли менять работу. Иногда из колеи может выбить то, что со стороны кажется мелочью — и в этом случае смело ищите новую работу.
Если вы постоянно миритесь с ситуацией, в которой вам дискомфортно, то рано или поздно это скажется на вашей продуктивности и самочувствии. Будьте смелее! Найдите то, что подходит вам больше, и уже в следующем году вы сможете стать намного счастливее. Если вам нужно подтянуть какие-то знания, а то и полностью сменить сферу деятельности — приходите учиться в Merion Academy.
Выходим на новый уровень. Для изучения следующей темы вы уже должны хорошо понимать связующее дерево. Связующее дерево (Spanning Tree Protocol STP) — это важная тема. Есть много вещей, которые могут пойти не так, и в этой статье мы рассмотрим ряд инструментов, которые мы можем использовать для защиты нашей топологии связующего дерева.
Для профессионалов
PortFast: мы видели это в статье о spanning tree и rapid spanning tree. Он настроит порт доступа как пограничный порт, поэтому он переходит в режим forwarding немедленно.
BPDU Guard: это отключит (err-disable) интерфейс, который имеет настроенный PortFast, если он получает BPDU.
BPDUFilter: это будет подавлять BPDU на интерфейсах.
Root Guard: это предотвратит превращение соседнего коммутатора в корневой мост, даже если он имеет лучший идентификатор моста.
UplinkFast: мы видели это в статье о связующем дереве. Он улучшает время конвергенции.
BackboneFast: мы также видели это в статье о связующем дереве. Оно улучшает время конвергенции, если у вас есть сбой косвенной связи.
UplinkFast и BackboneFast не требуются для rapid spanning tree, поскольку оно уже реализовано по умолчанию. Мы начнем с BPDUguard:
В топологии выше мы имеем идеально работающую топологию остовного дерева. По умолчанию связующее дерево будет отправлять и получать BPDU на всех интерфейсах. В нашем примере у нас есть компьютер, подключенный на интерфейсе fa0/2 коммутатора B. Есть кто-то, кто с враждебными намерениями мог бы запустить инструмент, который сгенерирует BPDU с превосходящим ID моста. Что же произойдет- так это то, что наши коммутаторы будут считать, что корневой мост теперь может быть достигнут через коммутатор B, и у нас будет повторный расчет связующего дерева. Звучит не очень хорошо, правда?
Можно поставить человека (хакера) в середине топологии для атаки так, чтобы никто не знал. Представьте себе, что хакер подключает свой компьютер к двум коммутаторам. Если хакер станет корневым мостом, то весь трафик от коммутатора А или коммутатора C к коммутатору В будет проходить через него. Он запустит Wireshark и подождет, пока произойдет чудо.
BPDUguard гарантирует, что, когда мы получаем BPDU на интерфейс, интерфейс перейдет в режим err-disable.
Чтобы продемонстрировать работу BPDUguard будем использовать два коммутатора. Настроем интерфейс fa0/16 коммутатора B так, что он перейдет в режим err-disable, если он получит BPDU от коммутатора C.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree bpduguard enable
Вот как вы включаете его в интерфейсе. Имейте в виду, что обычно вы никогда не будете делать это между коммутаторами. Вы должны настроить это на интерфейсах в режиме доступа, которые подключаются к компьютерам.
А-а... вот и наш интерфейс.
SwitchB(config-if)#no spanning-tree bpduguard
SwitchB(config-if)#shutdown
SwitchB(config-if)#no shutdown
Избавиться от BPDUguard можно используя команды shut/no shut, чтобы сделать интерфейс снова рабочим.
SwitchB(config)#spanning-tree portfast bpduguard
Вы также можете использовать команду spanning-tree portfast bpduguard. Это позволит глобально активировать BPDUguard на всех интерфейсах, которые имеют включенный portfast.
SwitchB(config)#spanning-tree portfast default
Portfast также может быть включен глобально для всех интерфейсов, работающих в режиме доступа.
Это полезная команда, позволяющая проверить свою конфигурацию. Вы видите, что portfast и BPDUGuard были включены глобально.
BPDUGuard переведет интерфейс в режим err-disable. Кроме того, можно фильтровать сообщения BPDU с помощью BPDUfilter. BPDUfilter может быть настроен глобально или на уровне интерфейса и есть разница:
Глобальный: если вы включите bpdufilter глобально, любой интерфейс с включенным portfast станет стандартным портом.
Интерфейс: если вы включите BPDUfilter на интерфейсе, он будет игнорировать входящие BPDU и не будет отправлять никаких BPDU.
Вы должны быть осторожны, когда включаете BPDUfilter на интерфейсах. Вы можете использовать его на интерфейсах в режиме доступа, которые подключаются к компьютерам, но убедитесь, что вы никогда не настраиваете его на интерфейсах, подключенных к другим коммутаторам. Если вы это сделаете, вы можете получить цикл.
Для демонстрации работы BPDUfilter мы будем снова использовать коммутатор B и коммутатор C.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree portfast trunk
SwitchB(config-if)#spanning-tree bpdufilter enable
Он перестанет посылать BPDU и будет игнорировать все, что будет получено.
SwitchB#debug spanning-tree bpdu
Вы не увидите никаких интересных сообщений, но если вы включите отладку BPDU, то заметите, что он больше не отправляет никаких BPDU. Если вы хотите, вы также можете включить отладку BPDU на коммутаторе C, и вы увидите, что нет ничего от коммутатора B.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#no spanning-tree bpdufilter enable
Давайте избавимся от команды BPDUfilter на уровне интерфейса.
SwitchB(config)#spanning-tree portfast bpdufilter default
Вы также можете использовать глобальную команду для BPDUfilter. Это позволит включить BPDUfilter на всех интерфейсах, которые имеют portfast.
Еще один вариант, с помощью которого мы можем защитить наше связующее дерево, - это использовать RootGuard. Проще говоря, RootGuard позаботится о том, чтобы вы не принимали определенный коммутатор в качестве корневого моста. BPDU отправляются и обрабатываются нормально, но, если коммутатор внезапно отправляет BPDU с идентификатором верхнего моста, вы не будете принимать его в качестве корневого моста. Обычно коммутатор D становится корневым мостом, потому что у него есть лучший идентификатор моста, к счастью, у нас есть RootGuard на коммутатое C, так что этого не произойдет!
Рассмотрим с вами конфигурацию с коммутатором B и коммутатором C.
SwitchB(config)#spanning-tree vlan 1 priority 4096
Давайте убедимся, что коммутатор C не является корневым мостом.
Вот как мы включаем RootGuard на интерфейсе.
SwitchB#debug spanning-tree events
Spanning Tree event debugging is on
Не забудьте включить отладку, если вы хотите увидеть события.
SwitchC(config)#spanning-tree vlan 1 priority 0
Давайте перенастроим коммутатор B, изменив приоритет на наименьшее возможное значение 0 на коммутаторе C. Он теперь должен стать корневым мостом.
Вот так коммутатор B не будет принимать коммутатор C в качестве корневого моста. Это заблокирует интерфейс для этой VLAN.
Вот еще одна полезная команда, чтобы проверить, работает ли RootGuard.
Связующее дерево становится все более безопасным с каждой минутой! Однако есть еще одна вещь, о которой мы должны подумать…
Если вы когда-либо использовали волоконные кабели, вы могли бы заметить, что существует другой разъем для передачи и приема трафика. Если один из кабелей (передающий или принимающий) выйдет из строя, мы получим однонаправленный сбой связи, и это может привести к петлям связующего дерева. Существует два протокола, которые могут решить эту проблему:
LoopGuard
UDLD
Давайте начнем с того, что внимательно рассмотрим, что произойдет, если у нас произойдет сбой однонаправленной связи.
Представьте себе, что между коммутаторами волоконно-оптические соединения. На самом деле имеется другой разъем для передачи и приема. Коммутатор C получает BPDU от коммутатора B, и в результате интерфейс стал альтернативным портом и находится в режиме блокировки.
Теперь что-то идет не так... transmit коннектор на коммутаторе B к коммутатору C был съеден мышами. В результате коммутатор C не получает никаких BPDU от коммутатора B, но он все еще может отправлять трафик для переключения между ними.
Поскольку коммутатор C больше не получает BPDU на свой альтернативный порт, он перейдет в forwarding режим. Теперь у нас есть one way loop (петля в один конец), как указано зеленой стрелкой.
Один из методов, который мы можем использовать для решения нашего однонаправленного сбоя связи — это настройка LoopGuard. Когда коммутатор отправляет, но не получает BPDU на интерфейсе, LoopGuard поместит интерфейс в состояние несогласованности цикла и заблокирует весь трафик!
Мы снова будем использовать эту топологию для демонстрации LoopGuard.
SwitchA(config)#spanning-tree loopguard default
SwitchB(config)#spanning-tree loopguard default
SwitchC(config)#spanning-tree loopguard default
Используйте команду spanning-tree loopguard по умолчанию, чтобы включить LoopGuard глобально
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree portfast trunk
SwitchB(config-if)#spanning-tree bpdufilter enable
В примере у нас нет никаких волоконных разъемов, поэтому мы не сможем создать однонаправленный сбой связи. Однако мы можем смоделировать его с помощью BPDUfilter на интерфейсе SwitchB fa0/16. Коммутатор C больше не будет получать никаких BPDU на свой альтернативный порт, что заставит его перейти в режим переадресации.
Обычно это вызвало бы петлю, но, к счастью, у нас есть настроенный LoopGuard. Вы можете увидеть это сообщение об ошибке, появляющееся в вашей консоли. Проблема решена!
SwitchC(config-if)#spanning-tree guard loop
Если вы не хотите настраивать LoopGuard глобально, вы т можете сделать это на уровне интерфейса.
Другой протокол, который мы можем использовать для борьбы с однонаправленными сбоями связи, называется UDLD (UniDirectional Link Detection). Этот протокол не является частью инструментария связующего дерева, но он помогает нам предотвратить циклы.
Проще говоря, UDLD — это протокол второго уровня, который работает как механизм keepalive. Вы посылаете приветственные сообщения, вы их получаете, и все прекрасно. Как только вы все еще посылаете приветственные сообщения, но больше их не получаете, вы понимаете, что что-то не так, и мы блокируем интерфейс.
Убедитесь, что вы отключили LoopGuard перед работой с UDLD. Мы будем использовать ту же топологию для демонстрации UDLD.
Существует несколько способов настройки UDLD. Вы можете сделать это глобально с помощью команды udld, но это активирует только UDLD для оптоволоконных линий связи! Существует два варианта для UDLD:
Normal (default)
Aggressive
Когда вы устанавливаете UDLD в нормальное состояние, он помечает порт как неопределенный, но не закрывает интерфейс, когда что-то не так. Это используется только для того, чтобы «информировать» вас, но это не предотвратит циклы.
Агрессивный - это лучшее решение, когда пропадает связь с соседом. Он будет посылать кадр UDLD 8 раз в секунду. Если сосед не отвечает, интерфейс будет переведен в режим errdisable.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#udld port aggressive
SwitchC(config)#interface fa0/16
SwitchC(config-if)#udld port aggressive
Мы будем использовать коммутатор B и C, чтобы продемонстрировать UDLD. Будем использовать агрессивный режим, чтобы мы могли видеть, что интерфейс отключается, когда что-то не так.
Если вы хотите увидеть, что UDLD работает, вы можете попробовать выполнить отладку.
Теперь самое сложное будет имитировать однонаправленный сбой связи. LoopGuard был проще, потому что он был основан на BPDUs. UDLD запускает свой собственный протокол уровня 2, используя собственный MAC-адрес 0100.0ccc.сссс.
SwitchC(config)#mac access-list extended UDLD-FILTER
SwitchC(config-ext-macl)#deny any host 0100.0ccc.cccc
SwitchC(config-ext-macl)#permit any any
SwitchC(config-ext-macl)#exit
SwitchC(config)#interface fa0/16
SwitchC(config-if)#mac access-group UDLD-FILTER in
Это творческий способ создавать проблемы. При фильтрации MAC-адреса UDLD он будет думать, что существует сбой однонаправленной связи!
Вы увидите много отладочной информации, но конечным результатом будет то, что порт теперь находится в состоянии err-disable.
Вы можете проверить это с помощью команды show udld.
LoopGuard и UDLD решают одну и ту же проблему: однонаправленные сбои связи.
Они частично пересекаются, но есть ряд различий, вот общий обзор:
LoopGuardUDLDНастройкиГлобально/на портуГлобально (для оптики)/на портуVLAN?ДаНет, на портуАвтосохранениеДаДа, но вам нужно настроить errdisable timeout.Защита от сбоев STP из-за однонаправленных связейДа - нужно включить его на всех корневых и альтернативных портахДа - нужно включить его на всех интерфейсах.Защита от сбоев STP из-за сбоев программного обеспечения (нет отправки BPDU)ДаНетЗащита от неправильного подключения (коммутационный оптический приемопередающий разъем)НетДа
Есть еще одна последняя тема, которую хотелось бы объяснить, это не протокол связующего дерева, но речь идет о избыточных ссылках, поэтому я оставлю ее здесь. Это называется FlexLinks.
Вот в чем дело: при настройке FlexLinks у вас будет активный и резервный интерфейс. Мы настроим это на коммутаторе C:
Fa0/14 будет активным интерфейсом.
Fa0/16 будет интерфейс резервного копирования (этот блокируется!).
При настройке интерфейсов в качестве FlexLinks они не будут отправлять BPDU. Нет никакого способа обнаружить петли, потому что мы не запускаем на них связующее дерево. Всякий раз, когда наш активный интерфейс выходит из строя, резервный интерфейс заменяет его.
SwitchC(config)#interface fa0/14
SwitchC(config-if)#switchport backup interface fa0/16
Именно так мы делаем интерфейс fa0/16 резервной копией интерфейса fa0/14.
Вы можете видеть, что связующее дерево отключается для этих интерфейсов.
Проверьте нашу конфигурацию с помощью команды show interfaces switchport backup. Вот и все, что нужно было сделать. Это интересное решение, потому что нам больше не нужно связующее дерево. Ведь в любой момент времени активен только один интерфейс.
SwitchC(config)#interface f0/14
SwitchC(config-if)#shutdown
Давайте закроем активный интерфейс.
Вы можете видеть, что fa0/16 стал активным. Вот и все.
Эта статья послужит хорошим руководством по вашему любимому верному спутнику Node.js – npm.
Node.js штурмует мир с 2009 года. Сотни тысяч систем были построены с помощью Node.js, что побудило сообщество разработчиков заявить, что «JavaScript поглощает программное обеспечение».
Одним из составляющий успеха Node стал npm – его популярный диспетчер пакетов, который позволяет разработчикам JavaScript быстро и легко обмениваться полезными пакетами, такими как lodash и moment.
На момент написания этой статьи npm поспособствовал публикации более 1,3 миллионов пакетов с еженедельной загрузкой более 16 миллиардов! Эти цифры являются фантастическими для любого программного инструмента. Итак, а теперь давайте поговорим о том, что же такое npm.
Что такое NPM?
NPM, или Node Package Manager, - это диспетчер пакетов для среды выполнения JavaScript Node.js.
Он также известен как “Ninja Pumpkin Mutants", "Nonprofit Pizza Makers", а также множество других случайных имен, с которыми вы можете поэкспериментировать и, возможно, внести свой вклад в расширения npm.
NPM состоит из двух основных частей:
инструмент CLI (command-line interface – интерфейс командной строки) для публикации и загрузки пакетов
онлайн-репозиторий, в котором размещаются пакеты JavaScript.
Для более наглядного представления можно представить, что репозиторий npmjs.com – это распределительный центр, который получает пакеты товаров от продавцов (авторов пакетов npm) и распространяет их среди покупателей (пользователей пакетов npm).
Для того, чтобы облегчить данный процесс, в распределительном центре npmjs.com работает армия трудолюбивых вомбатов (CLI), которые назначаются в качестве личных помощников для каждого отдельного клиента npmjs.com. таким образом, пакеты доставляются разработчикам JavaScript следующим образом:
А процесс публикации пакеты для ваших коллег по JavaScript выглядит примерно так:
Ну и да, вомбаты не настоящие, если что, а для наглядности :)
Давайте посмотрим, как же эта армия вомбатов помогает разработчикам, которые хотят использовать пакеты JavaScript в своих проектах. Мы также будем наблюдать то, как они помогают мастерам по открытом исходному коду выпускать свои потрясающие библиотеки в свет.
package.json
Каждый проект в JavaScript – будь то Node.js или приложение браузера – может рассматриваться как пакет npm с собственной информацией о пакете и функциями package.json для описания проекта.
Можно представить, что package.json – это этикетки на коробках с npm, которые доставляет ваша армия вомбатов.
package.json создается при запуске npm init для инициализации проекта JavaScript/Node.js со следующими основными метаданными, предоставленными разработчиками:
name: имя вашей библиотеки/проекта JavaScript.
version: версия вашего проекта. Часто при разработке приложений этим полем пренебрегают, так как нет очевидной необходимости в управлении версиями библиотек с открытым исходным кодом. Но тем не менее, эта информация может пригодиться в качестве источника версии развертывания.
description: описание проекта.
license: лицензия на проект.
npm-скрипты
package.json также поддерживает scripts (скрипты), которые можно определить для запуска инструментов командной строки, установленных в локальном контексте проекта. Например, скрипты проекта npm могут выглядеть примерно так:
{
"scripts": {
"build": "tsc",
"format": "prettier --write **/*.ts",
"format-check": "prettier --check **/*.ts",
"lint": "eslint src/**/*.ts",
"pack": "ncc build",
"test": "jest",
"all": "npm run build && npm run format && npm run lint && npm run pack && npm test"
}
}
При этом eslint, prettier, ncc, jest не обязательно должны быть установлены как глобальные исполняемые файлы, а скорее даже как локальные для вашего проекта внутри node_modules/.bin/.
Недавнее введение npx позволяет запускать эти команды в области видимости проекта node_modules точно так же, как глобально установленную программу, просто добавив префикс npx ... (то есть npx prettier --write **/*.ts).
dependencies VS devDependencies
Эти двое представляют собой объекты типа «ключ-значение», где ключ – это имена библиотек npm, а значение – это их версии в семантическом формате. Ниже представлен пример шаблона действия TypeScript на GitHub:
{
"dependencies": {
"@actions/core": "^1.2.3",
"@actions/github": "^2.1.1"
},
"devDependencies": {
"@types/jest": "^25.1.4",
"@types/node": "^13.9.0",
"@typescript-eslint/parser": "^2.22.0",
"@zeit/ncc": "^0.21.1",
"eslint": "^6.8.0",
"eslint-plugin-github": "^3.4.1",
"eslint-plugin-jest": "^23.8.2",
"jest": "^25.1.0",
"jest-circus": "^25.1.0",
"js-yaml": "^3.13.1",
"prettier": "^1.19.1",
"ts-jest": "^25.2.1",
"typescript": "^3.8.3"
}
}
Эти пакеты, от которых зависит приложение, (dependencies) устанавливаются с помощью команды npm install с флагами --save и --save-dev. Они предназначены для использования в эксплуатационной среде и среде разработки/тестирования соответственно. В следующем разделе мы рассмотрим подробнее, как установить эти пакеты.
Между тем, важно понимать, что означают знаки, которые могут стоять перед семантической версией (при условии, что вы ознакомились с моделью semver major.minor.patch):
^: последний второстепенный выпуск. Например, спецификация ^1.0.4 может установить версию 1.3.0, если это последняя дополнительная версия основной серии 1.
~: последний выпуск исправления. Аналогично ^ для второстепенных выпусков – спецификация ~1.0.4 может установить версию 1.0.7, если это последняя второстепенная версия во второстепенной серии 1.0.
Все точные версии пакетов будут задокументированы в созданном файле package-lock.json.
package-lock.json
Этот файл описывает точные версии пакетов, используемых в проекте JavaScript npm. Если package.json - это общая описательная этикетка, то package-lock.json - это список ингредиентов.
И точно так же, как мы обычно не читаем список ингредиентов продукта (если только вам совсем нечем себя занять или вам действительно нужно знать состав), так и package-lock.json не предназначен для того, чтобы разработчики читали его построчно (если только вы отчаянно не пытаетесь решить проблемы из области «как это работает»).
package-lock.json обычно создается с помощью команды npm install, а также считывается нашим инструментом NPM CLI, чтобы обеспечить воспроизведение сред сборки для проекта в помощью npm ci.
Как эффективно управлять NPM в качестве «покупателя»
Учитывая тот факт, что было опубликовано 1,3 миллиона пакетов, а загрузок было 16 миллиардов, можно сделать вывод, что большинство пользователей npm используют его именно для загрузки пакетов. Поэтому стоит знать, как пользоваться этим мощным инструментом.
npm install
Это наиболее часто используемая команда при разработке приложений JavaScript/Node.js.
По умолчанию команда npm install устанавливает последнюю версию пакета со знаком версии ^. Команда npm install в контексте проекта npm загружает пакеты в папку node_modules проекта в соответствии со спецификациями package.json, обновляя версию пакета (и, в свою очередь, повторно создавая package-lock.json) везде, где это возможно, основываясь на соответствиях версии ^ и ~.
Вы можете указать глобальный флаг -g, если хотите установить пакет в глобальном контексте – вы сможете использовать его в любом месте на вашем компьютере (это обычно используется для пакетов инструментов командной строки, таких как like-server).
npm делает установку пакетов JavaScript настолько простой, что эту команду часто используют неправильно. Это приводит к тому, что npm становится предметом огромного количества шуток со стороны программистов, таких как эти:
Здесь на помощь приходит флаг --production! В предыдущем разделе мы обсудили dependencies и devDependencies, предназначенные для использования в эксплуатационной среде и среде разработки/тестирования соответственно. Этот флаг определяет то, как создаются отличительные признаки в node_modules.
Добавив этот флаг к команде npm install, мы сможем устанавливать пакеты только из dependencies, тем самым резко уменьшая размер наших модулей node_modules до необходимого для запуска и работы наших приложений.
npm ci
Итак, если команда npm install --production оптимальна для эксплуатационной среды, то существует ли команда, которая будет оптимальная для моей локальной разработки и настройки тестирования?
Ответ: npm ci.
Точно так же, как если package-lock.json еще не существует в проекте, то он генерируется всякий раз при вызове команды npm install, npm ci использует этот файл для загрузки точной версии каждого отдельного пакета, от которого зависит проект.
Именно так мы можем убедиться в том, что контекст нашего проекта остается одинаковым на любом оборудовании, будь то наши ноутбуки, которые мы используем для разработки, или среды сборки CI (Continuous Integration – непрерывная интеграция), такие как Github Actions.
npm audit
Из-за огромного количества пакетов, которые были опубликованы и могут быть легко установлены, пакеты npm уязвимы из-за недобросовестных авторов с недобрыми намерениями.
Понимая, что в экосистеме возникла проблема, организация npm.js предложила ввести команду npm audit. Она поддерживает список брешей в системе безопасности, с помощью которых разработчики могут проверять свои пакеты с помощью этой команды.
npm audit предоставляет разработчикам информацию об уязвимостях и о том, существуют ли версии с исправлениями для обновления. Например:
Если исправления доступны в следующих некритических обновлениях версии, то команду npm audit fix можно использовать для автоматического обновления версий затронутых пакетов.
Как эффективно управлять NPM в качестве «продавца»
Мы рассмотрели, как использовать инструмент NPM CLI в качестве потребителя, но что насчет его эффективного использования в качестве автора (и, возможно, становления мастером JavaScript по открытому исходному коду?)?
npm publish
Отправить пакет в распределительный центр npmjs.com очень просто – достаточно просто запустить команду npm publish. Сложность заключается в определении версии пакета, но она не относится к авторам пакетов npm.
Практическое правило согласно semver.org:
ОСНОВНАЯ (MAJOR) версия при внесении несовместимых изменений API;
ВТОРОСТЕПЕННАЯ (MINOR) версия при добавлении функциональности и сохранении совместимости;
Версия ИСПРАВЛЕНИЯ (PATCH) при исправлении ошибок и сохранении совместимости с предыдущими версиями.
Это очень важно – следовать приведенному выше правилу при публикации ваших пакетов, чтобы не нарушать чей-либо программный код, так как соответствие версий по умолчанию в npm – ^ (она же следующая второстепенная версия).