Действительно, используя scope можно указать для него реджестри строкой @my:registry=http://corporate.npm. Почему при этом он не берёт реджестри из лок файла - осталось загадкой. Эээ - энтуитивность.
Paul_Vasko, в доке phpstorm написано, что конфиг сниффера подхватывается из composer.json, если этого не происходит, то надо гуглить конкретные решения и применять их.
Skelman, если для запросов используется axios, то создать axios instance и спрятать все запросы по сети туда. Работу с dom тоже вынести в отдельный модуль. Не юзать глобальные переменные, не мутировать объекты, сократить try catch до одного на верхнем уровне приложения. Надо чтобы остались данные на входе, данные на выходе + написать тесты на всё это.
profesor08, потому что в таком виде map просто заблокирует поток пока не соберёт в себе все необходимые промисы. Зачем писать асинхронный код, если в нём юзаются синхронные функции? )
Skelman, можно написать код, который будет на локалке в разный день выдавать разные результаты, в этом и прикол работы с асинхронностью - либо делаешь по её правилам, либо получаешь нестабильное поведение с невозможностью воспроизвести багу. Самое простое - пойти от стандартных практик написания кода, минимизировав варианты где что-то может пойти не так.
Malkolm, конкретно с ангуляром я не работал, но обычно фреймворк упрощает работу с чем-либо, поэтому нужно изучать его событийную модель и приходить примерно к такому же коду, как это было бы для самого простого случая
smmaxim, или смотрите в сторону оркестрации. У нас сейчас Rancher и Gitlab CI/CD, но девопсам чем-то Ранчер не зашёл и мигруют на Кубер. А если ещё и AWS, то там всё сводится к настройке через интерфейс. Колхозить - себе дороже. Раз минутный простой стал серьёзными потерями, нет смысла жмотиться на полноценные продакшн-решения.
MeG1tsune, только изучить технологию, изучить устройство какой-нибудь готовой либы и запилить своё, либо установить через npm и научиться ей пользоваться. Большего не скажу, т.к. я с этой технологией работаю как юзер, а не девелопер )
MeG1tsune, если вы ещё не работали с oauth, то рекомендую. У ВК он есть, например. Процесс для "клиента" выглядит следующим образом:
1. Зарегистрироваться в сервисе как юзер под логином-паролем;
2. "Создать" приложение в сервисе - ему выдаётся appId;
3. Авторизоваться в сервисе через приложение - вернётся токен пользователя вашего приложения, который будет действовать сколько-то времени.
Поскольку подразумевается, что при oauth есть redirect_uri, то указывать не домен приложения, а домен бэка, где хранятся данные и записывать авторизацию туда. Соответственно, ваше приложение без домена просто запрашивает с бэка свою авторизацию повторно и ему прилетают все необходимые данные с которыми он уже выполняет запросы.
alex-1917, из вашего же вопроса:
"Как правильнее выгружать" и "не обойтись без Promise?"
Я вам и сделал акцент на то, что современные решения должны быть асинхронные и fetch в этом поможет.
На тех же ресурсах где вы берёте информацию есть прекрасные статьи про всё что нужно - fetch, const, let. Просто изучите и попробуйте на практике, а единый code style, solid, di и чистые детерминированные функции помогут построить архитектуру вашего проекта без потери в качестве.
Антон Швец, ключевая фраза "без специфической задачи". Я думаю, что у автора не специфическая задача, а знакомство с жсным ООП, что нужно делать более структурированно пополам с чтением книг, а не цитировать learnjs на toster )
alex-1917, таки ослик не поддерживается даже Майками, зачем на него ориентироваться при создании нового кода? Тогда уж надо смотреть и на DOM API, там ведь тоже есть различия и тот же textContent там не поддерживается в каких-то версиях. + опять же, синхронные запросы по сети на фронте - это просто не рационально, даже если ваш сервис отвечает за 1 миллисекунду.
@my:registry=http://corporate.npm
. Почему при этом он не берёт реджестри из лок файла - осталось загадкой. Эээ - энтуитивность.