в дебаге про body ничего, ладно, погуглю, может реально метод не тот взял

парни, такой вопрос: в koa есть такой роут: .get('/:id', async (ctx) => { const result = await fakeResponse(); if (result) { ctx.body = JSON.stringify(result); console.log(ctx.body); } else { ctx.status = 204; } }) в реакт компоненте: fetchData = (url) => { this.setState({ loading: true, error: null }); fetch(`http://localhost:3001${url}`) .then((data) => this.setState({ loading: false, data })) .catch((error) => this.setState({ loading: false, error })); } в console.log(ctx.body); выдаёт то что надо. а в реакт-компонент прилетатает вот это: Response body: (...) bodyUsed: false headers: Headers ok: true redirected: false status: 200 statusText: "OK" type: "cors" url: "http://localhost:3001/12/"

вопрос по аллокации памяти const arr = [] arr[10000] = 1 сколько отожрет?

sizeof(int) + оверхед на массив или sizeof(int) * 10000 + оверхед на массив?

https://github.com/lerna/lerna

кто юзает ?

sizeof(int) + оверхед на массив или sizeof(int) * 10000 + оверхед на массив?

Скорее второе (но не уверен), но важнее то, что sparse array медленнее обычных, по возможности нужно их избегать

кто юзает ?

Я

Я

Для каких проектов

каков профит, по сравнению, просто с репой без пакетов ?

парни, такой вопрос: в koa есть такой роут: .get('/:id', async (ctx) => { const result = await fakeResponse(); if (result) { ctx.body = JSON.stringify(result); console.log(ctx.body); } else { ctx.status = 204; } }) в реакт компоненте: fetchData = (url) => { this.setState({ loading: true, error: null }); fetch(`http://localhost:3001${url}`) .then((data) => this.setState({ loading: false, data })) .catch((error) => this.setState({ loading: false, error })); } в console.log(ctx.body); выдаёт то что надо. а в реакт-компонент прилетатает вот это: Response body: (...) bodyUsed: false headers: Headers ok: true redirected: false status: 200 statusText: "OK" type: "cors" url: "http://localhost:3001/12/"

https://developer.mozilla.org/ru/docs/Web/API/Fetch_API

Скорее второе (но не уверен), но важнее то, что sparse array медленнее обычных, по возможности нужно их избегать

спасибо

лерна под отдельной репой у вас, или по репам с проектами размазана ?

Для каких проектов

Обкатал в telegram-mtproto, (там шесть пакетов разного назначения) теперь в закрытые проекты подтягиваю

лерна под отдельной репой у вас, или по репам с проектами размазана ?

Монорепо

ну и каждый отдельный проект, тянет из этой монорепы по пакетикам ?

Обкатал в telegram-mtproto, (там шесть пакетов разного назначения) теперь в закрытые проекты подтягиваю

Если в 6 связанных пакетах это понятно. Как в остальных случаях

спасибо

Ближе ко второму Но все предыдущие у тебя будут забиты indefined

ребят, а еще, не покажите, плиз, 2 объекта sequelize со связью one-to-many, если не сложно? ну на подобие User и Post

Я Кстати тоже пытался как-то со связями работать. Но так и не смог. Там вообще как-то всё сложно сделано. Так что я вообще бросил эту идею.

каков профит, по сравнению, просто с репой без пакетов ?

Смысл в том, что становится меньше проблем с зависимостями в случае связных проектов - всё всегда юзает актуальную версию

почему бы просто не заюзать второй сорс фолдер под гитом, без пакетиков ?

почему бы просто не заюзать второй сорс фолдер под гитом, без пакетиков ?

Лерна сама обновляет зависимости и версии из монорепо

почему бы просто не заюзать второй сорс фолдер под гитом, без пакетиков ?

Ну например фронт и бэк. Они будут требовать разных пакетов, lerna bootstrap - и всё само устанавливается и линкуется если надо

хм... тогда получается три физических репозитория, фронт , бэк, шаред. И если я делаю что-то в шаред, то должен вносить изменения ещё в двух репах и их коммитить

Ну например фронт и бэк. Они будут требовать разных пакетов, lerna bootstrap - и всё само устанавливается и линкуется если надо

Я вот думаю проект так писать. Бизнес логику вынести в отдельный пакет. Это норм?

шаред - монорепа, со всеми пакетами

хм... тогда получается три физических репозитория, фронт , бэк, шаред. И если я делаю что-то в шаред, то должен вносить изменения ещё в двух репах и их коммитить

А с лерна это один репо

Я вот думаю проект так писать. Бизнес логику вынести в отдельный пакет. Это норм?

вкусная идея тоже хочетсо опыт

спасибо

На самом деле, массив в js-е - это объект. Выставив 10000 у тебя этому индексу присвоится значение и все

хм... тогда получается три физических репозитория, фронт , бэк, шаред. И если я делаю что-то в шаред, то должен вносить изменения ещё в двух репах и их коммитить

Наоборот не должен

спасибо

Так что по памяти оно займет немного места

т.е. мой модуль с точкой входа, это тоже часть монорепа. Будь то фронт или бэк

Так что по памяти оно займет немного места

да, супер там просто массивы в массивах (yo dawg) и последний уровень не охота в объект класть

пакет в монорепе, под лерной

там пара ключей, но больших

Я вот думаю проект так писать. Бизнес логику вынести в отдельный пакет. Это норм?

Если она действительно общая и есть смысл, то норм

https://developer.mozilla.org/ru/docs/Web/API/Fetch_API

Благодарю. всего то надо дописать .then(r=> r.json())

да, супер там просто массивы в массивах (yo dawg) и последний уровень не охота в объект класть

Ты можешь все, что угодно использовать в качестве ключа, JS приведет это к строке

пакет в монорепе, под лерной

Тогда откуда "вносить изменения в остальные пакеты"? В принципе, lerna сама следит за актуальностью версий зависимостей

Благодарю. всего то надо дописать .then(r=> r.json())

Доки- наше все. Нужно уметь отличать вопросы по докам, вопросы, которые можно найти в интернете и вопросы, которые лучше спросить напрямую

Тогда откуда "вносить изменения в остальные пакеты"? В принципе, lerna сама следит за актуальностью версий зависимостей

пока только думаю, что и как

Если она действительно общая и есть смысл, то норм

Глянь на atmx.in/rest, atmx.in/rest-ex, atmx.in/rest-koa Есть смысл в монорепо?

А если установить значение пустого массива со 100500-ым индексом, то он же насоздаёт пустых элементов до него? Это медленно?

А если установить значение пустого массива со 100500-ым индексом, то он же насоздаёт пустых элементов до него? Это медленно?

Не создаёт по факту

Плюс lerna run <comand> -- запустить сразу всо всех репах с такой командой. От банального lerna run start до каких-то более сложных вариантов)

Не создаёт по факту

Но вывод напечатает вот такое: [ , , , , ... , 'myValue']

Это как понимать?

Это как понимать?

Просто печатать до индекса

Это называется "дырка"

Плюс lerna run <comand> -- запустить сразу всо всех репах с такой командой. От банального lerna run start до каких-то более сложных вариантов)

спасибо. Ещё вопрос. Если у меня несколько пакетов - это несколько разных софтин.

То есть, он просто создаёт элемент и лишней работы не делает?

он делает length = 100500, сами элементы не создает

сейчас я делаю апдейт пакета под гитом и перезапускаю софт. Удобнее ли это будет сделать с лерной, без гита и через самоапдейт софта через npm update ?

То есть, он просто создаёт элемент и лишней работы не делает?

Только при попытке их все перебрать

Не, при попытке перебрать тоже не делает

Только при попытке их все перебрать

Ну, это-то понятно.

Не, при попытке перебрать тоже не делает

О. Вот оно как

Не, при попытке перебрать тоже не делает

Эм... У него внутри типа индекса что-то есть?

Стандартный map не перебирает элементы которых нет

Ну логически массив это просто объект

Не, при попытке перебрать тоже не делает

А если [...list] ?

Но если я сделаю map, то он переберёт и пустые значения.

Да ладно?

нет, в map/forEach/... проверка на существование

А если [...list] ?

Так сделает, да

ERROR: S client not available

то есть for of отдаст пустые элементы, forEach - нет

Да, вот так и думал

А... Вспомнил.

Нужно сначала сделать fill()

Глянь на atmx.in/rest, atmx.in/rest-ex, atmx.in/rest-koa Есть смысл в монорепо?

@zerobias что думаешь

сейчас я делаю апдейт пакета под гитом и перезапускаю софт. Удобнее ли это будет сделать с лерной, без гита и через самоапдейт софта через npm update ?

lerna publish --skip-npm проапдейтит все версии зависимостей между пакетами и сделает аккуратный релиз обновленных пакетов в git. В prepublish проектов у тебя скорее всего изначально будет грамотная пересборка, поэтому фактически одной командой ты обновляешь всё, делаешь пуш в гит и получаешь воркспейс с актуальным проектом)

@zerobias что думаешь

Думаю можно

У меня и был похожий кейс - много пакетов, держать которые в одном нецелесообразно - там и зависимости для ноды, и чисто браузерные штуки, в общем юзеры бы офигели от списка deps))

нет, в map/forEach/... проверка на существование

Нет проверки на существование

Плюс ещё один бонус монорепы - можно убрать из devDeps каждого пакета нерелевантные ему штуки. Работая с четырьмя пакетами, на все будет всего один инстанс eslint, один flow (вот от этого особенно хорошо, учтывая его жручесть) и так далее

А, нет, есть Я неправильно затестил

Плюс ещё один бонус монорепы - можно убрать из devDeps каждого пакета нерелевантные ему штуки. Работая с четырьмя пакетами, на все будет всего один инстанс eslint, один flow (вот от этого особенно хорошо, учтывая его жручесть) и так далее

Резолвится из нпмскриптс норм?

Более того, .map пробежит только по числовым индексам

В плане?

В плане?

Ну установка дев флоу идёт в корень же

Ну да

В корне - свой package.json)

А юзать из пакета, в скриптах нет ../../node_modules/.bin/flow ?

Так а зачем так юзать, у тебя просто будет один vs code workspace

Билдить например

Не обязательно флоу там

Ещё вопрос есть. Если в лерна ставить независимые версии в конфиге, обновление minor версии изменит всё пакеты или только изменившиеся? Он поставит всем одну версию или в каждом обновит?

Я читал доку и тестил. Но результаты не соответствовали доке

Ещё вопрос есть. Если в лерна ставить независимые версии в конфиге, обновление minor версии изменит всё пакеты или только изменившиеся? Он поставит всем одну версию или в каждом обновит?

Обновляешь минорную версию пакета -> лерна смотрит какие пакеты зависят от данного -> если версия не соответствует записи в package.json, то обновить и их тоже

Ааап

Обновляешь минорную версию пакета -> лерна смотрит какие пакеты зависят от данного -> если версия не соответствует записи в package.json, то обновить и их тоже

Огромное спасибо

А версию конкретного пакета руками да?

можно ли из master-кластера вызвать метод воркера и получить результат ?

А версию конкретного пакета руками да?

Как пожелаешь) Вообще в идеале при обычном publish лерна просто делает diff и смотрит, какие пакеты изменились со времени последного git release tag и апдейтит их версию

Плюс есть lerna publish --force-publish=package-name

Как пожелаешь) Вообще в идеале при обычном publish лерна просто делает diff и смотрит, какие пакеты изменились со времени последного git release tag и апдейтит их версию

Вот теперь я понял. Спасибо