M
Если вы где-то видите «бычинье» с моей стороны - укажите мне на это. Вы ответили, я вас поправил, не более
"жабишь", он перепутал😅
Size: a a a
2019 November 07
M
Скомпилированный проект или что?
ну эта scirra. что оно из себя представляет?
P
Это Двиг, на js, можно открыть двиг прям в браузере, можно использовать десктопную версию, поддерживает кроссплатформерный экспорт, под все популярные платформы
SG
Друзя у меня вопрос по генераторам. Нужно написать функцию котврая вызовится в первый 8аз запомнит аргвумнет а во вторвй раз вызовет другую функцию с первым и вторым аргументом
M
Это Двиг, на js, можно открыть двиг прям в браузере, можно использовать десктопную версию, поддерживает кроссплатформерный экспорт, под все популярные платформы
слишком много двигов🤤 коротенький скрипт где исполняется? тут нужно тонну документации изучить похоже, перед тем как коротенький скрипт писать..
M
Друзя у меня вопрос по генераторам. Нужно написать функцию котврая вызовится в первый 8аз запомнит аргвумнет а во вторвй раз вызовет другую функцию с первым и вторым аргументом
а в третий раз что произойдет?
M
нечего
var f;
f = function(){
var param, count;
param = null;
count = 0;
return function(a){
switch (count) {
case 0:
count = count + 1;
param = a;
break;
case 1:
count = count + 1;
callSomeOtherFunction(param, a);
}
};
}();
ꟿ
Почему при
slice(-1) если Array[1] то он вернет то же самое, а не пустой?AP
-1 это с конца
SG
var f;
f = function(){
var param, count;
param = null;
count = 0;
return function(a){
switch (count) {
case 0:
count = count + 1;
param = a;
break;
case 1:
count = count + 1;
callSomeOtherFunction(param, a);
}
};
}();
Большое спасибо очень красивый код
V
Большое спасибо очень красивый код
Рофл?
I@
Приветы. Я правильно понимаю, что для проекта на js (vue, nuxt) имеет смысл искать QA на js, чтобы, так сказать, стек вышел полностью гомогенным?
I@
иногда тянет на что-то гомогенное. раньше тесты писались на питоне, но вот вдруг мне показалось очень привлекательным сделать всё при всё на js
SG
Рофл?
нет реално.
SG
Без сарказма. Клевый код
fe
Всем хай
Мне тут мысль пришла по поводу
На фронте вроде бы исторически разделение было условное
И мы в командах всегда придерживались такого правила:
— те либы, которые попадут в продакшн бандл, ставим в
— те либы, код которых не попадает в бандл, но помогает его собирать, идёт в
В принципе логика понятная и помогает некий порядок иметь. К тому же иногда полезно глазом увидеть, не попадает ли какая-нибудь известно-большная либа в банлд, глянув только на "dependencies"
Но вот я сейчас подумал, что вообще-то в проектах бывают и по-настоящему *dev*
И может быть есть смысл именно эти либы ставить в
Мне тут мысль пришла по поводу
dependencies и devDependenciesНа фронте вроде бы исторически разделение было условное
И мы в командах всегда придерживались такого правила:
— те либы, которые попадут в продакшн бандл, ставим в
dependencies— те либы, код которых не попадает в бандл, но помогает его собирать, идёт в
devDependencies. То есть это всякие вебпаки, babel, лоудеры, тайпскрипты и т.п.В принципе логика понятная и помогает некий порядок иметь. К тому же иногда полезно глазом увидеть, не попадает ли какая-нибудь известно-большная либа в банлд, глянув только на "dependencies"
Но вот я сейчас подумал, что вообще-то в проектах бывают и по-настоящему *dev*
devDependencies. Это либы, которые реально нужны только для разработки, но не нужны ни в продакшн бандле, ни для того, чтобы этот бандл собрать. Это такие штуки, как сторибуки (styleguidist, docz и т.п.), дев-серверы, линтеры и подобноеИ может быть есть смысл именно эти либы ставить в
devDependencies? И можно было бы настроить CI не устаналивать devDependencies вообще. Будет быстрее сборкаI@
devDevDependenciesan
Всем хай
Мне тут мысль пришла по поводу
На фронте вроде бы исторически разделение было условное
И мы в командах всегда придерживались такого правила:
— те либы, которые попадут в продакшн бандл, ставим в
— те либы, код которых не попадает в бандл, но помогает его собирать, идёт в
В принципе логика понятная и помогает некий порядок иметь. К тому же иногда полезно глазом увидеть, не попадает ли какая-нибудь известно-большная либа в банлд, глянув только на "dependencies"
Но вот я сейчас подумал, что вообще-то в проектах бывают и по-настоящему *dev*
И может быть есть смысл именно эти либы ставить в
Мне тут мысль пришла по поводу
dependencies и devDependenciesНа фронте вроде бы исторически разделение было условное
И мы в командах всегда придерживались такого правила:
— те либы, которые попадут в продакшн бандл, ставим в
dependencies— те либы, код которых не попадает в бандл, но помогает его собирать, идёт в
devDependencies. То есть это всякие вебпаки, babel, лоудеры, тайпскрипты и т.п.В принципе логика понятная и помогает некий порядок иметь. К тому же иногда полезно глазом увидеть, не попадает ли какая-нибудь известно-большная либа в банлд, глянув только на "dependencies"
Но вот я сейчас подумал, что вообще-то в проектах бывают и по-настоящему *dev*
devDependencies. Это либы, которые реально нужны только для разработки, но не нужны ни в продакшн бандле, ни для того, чтобы этот бандл собрать. Это такие штуки, как сторибуки (styleguidist, docz и т.п.), дев-серверы, линтеры и подобноеИ может быть есть смысл именно эти либы ставить в
devDependencies? И можно было бы настроить CI не устаналивать devDependencies вообще. Будет быстрее сборкачто мешает кэщировать ноде_модулес в ci?
an
Будет у тебя установка за 0.00 секунд