Как дебажить на серверных файлах из VSCode?

День добрый.
Подскажите.
Как debug-ить на серверных файлах?

Работаю на VSCode.
С front-ом вопросов нет. Server загадкой остается.

0

Сообщение от Usaga Да нет, не синоним. Авария - внештатная ситуация, с проблемами. Отладка - просто изучение работы участка кода. Не только для поиска проблем, но и просто для того, чтобы разобраться что происходит.

Об этом тебе и говорил там. Всё работает не зависимо друг от друга , под разными командами.

Там, на репе, вчера обновил.
На примере бэкенда можешь увидеть свзязь.
Для одного проекта одно ядро и 2 sub-ядра

В Ядро заливаем то, что пригодится в этих 2-х sub-ядрах (фронт и бэкенд).
Эти sub-ядра (в данном примере конкретно и только бэкенд ) получают свои зависимости.

Все работает под разными/независимыми (фронт и бэка) командами.
Все команды из корня.

Обрати внимание на package.json и атрибут workspaces/workspace.
Фронт не трогай. Над ним на заморачивался.

Как ты и говоришь, только ядро одно.

Сообщение от Usaga Это должны быть два проекта, пускай и в одной корневой папке. Но у них не должно быть общего package.json

.
Как вариант - да.
Но дока npm затрагивает workspaces из package.json/
Значит мой вариант допустим.

То , что обычно заливается в само ядро ни как не мешает работать фронту НЕЗАВИСИМО от бэки.
Поэтому, только если заказчик потребует, то разнесу по разным.

Сообщение от Usaga Ты вообще где и как с нодой работать учился?

Дока npm затрагивает workspaces из package.json/
Значит мой вариант допустим.

Учился 2 года в Нетологии. Там с практическим опытом, а не теоретики.
Они тоже настаивали на твоей версии. Но остаюсь на своём.
Ещё раз, Все работает из 1 ядра. Остальное как ты говоришь, разные команды + независимость.
Почитай workspaces.
Тебе ни кто не мешает развернуть проект одной командой или можешь двумя. Тут дело вкуса.

Сообщение от Usaga Не вороти херню и отладка будет нормально работать

Ни кто не говорил, что она плохо работает. Был фактически вопрос - как видеть данные , в нужном месте при условии, что код НЕ предназначен для браузера.

0

Сообщение от Tryd0g0lik Ещё раз, Все работает из 1 ядра.

А зачем? Какой практический смысл ты в этом видишь? Я вот вижу дополнительные проблемы и ничего более.

Сообщение от Tryd0g0lik Ни кто не говорил, что она плохо работает. Был фактически вопрос - как видеть данные , в нужном месте при условии, что код НЕ предназначен для браузера.

Открой в VSCode папку с беком (где package.json бека лежит) и пробуй запускать там отладку. Но в целом совет такой: если ты решил через жопу (но допустимую с точки зрения NPM) организовать проект и работать с ним, то сам и разбирайся как там отладку прикручивать. При нормальной организации проектов оно всё работает из коробки.

Добавлено через 1 минуту

Сообщение от Tryd0g0lik Поэтому, только если заказчик потребует, то разнесу по разным.

Обычно заказчику до фонаря. Ему нужно, чтобы это работало и собиралось потом.

0

Сообщение от Usaga А зачем? Какой практический смысл ты в этом видишь? Я вот вижу дополнительные проблемы и ничего более

Тут дело вкуса.
Мне вот нравится когда через команду 'cd'. заходишь в один адрес и больше не бегаешь. Буквально всё работает с одного места и не зависимо друг от друга.

Сообщение от Usaga если ты решил через жопу (но допустимую с точки зрения NPM) организовать проект и работать с ним, то сам и разбирайся как там отладку прикручивать

Ну тебя ни кто силой сюда не гнал. Сам пришел. И кто сказал, что твой вариант ни есть через жопу? Твои наставники в твои первые минуты знакомства с редактором кода? (без ответа давай).
Нет стандарта который говорит , что твой вариант (но допустимый с точки зрения NPM) есть идеал, а мой нет.
Если большинство выбрало твой вариант, это не говорит что ты есть элита.

Если желаешь высказать мысль, то вначале развивай свой диалект более широким словарным запасом.

Мне все мнения интересно почитать если этот кто-то не решил , что он есть элита, а остальное
через анус.

Добавлено через 15 минут

Сообщение от Usaga Какой практический смысл ты в этом видишь?

Если ещё желание осталось, перечисли плюсы своего варианта по отношению к моему (с той картиной которую видишь). Только не забудь о словарном запасе.

1

Сообщение от Tryd0g0lik Мне вот нравится когда через команду 'cd'. заходишь в один адрес и больше не бегаешь. Буквально всё работает с одного места и не зависимо друг от друга.

А зачем тут вообще бегать? Открой ДВЕ VSCode и всё. Это обычная практика.

Сообщение от Tryd0g0lik И кто сказал, что твой вариант ни есть через жопу?

Тем, что отладка работает из коробки, как надо. Это не аргумент?

Сообщение от Tryd0g0lik Нет стандарта который говорит , что твой вариант (но допустимый с точки зрения NPM) есть идеал, а мой нет.

Нет тут никаких стандартов. Есть подходы, которые создают больше проблем, а есть те, что создают меньше. Твой создаёт больше проблем.

Сообщение от Tryd0g0lik Если ещё желание осталось, перечисли плюсы своего варианта по отношению к моему (с той картиной которую видишь). Только не забудь о словарном запасе.

Твой подход плох тем, что связывает два по сути независимых проекта. Представляя каждый независимый проект как модуль некого корневого проекта (который и не нужен вовсе). Общим package.json, общей корневой папкой node_modules. Создаёт проблемы, типа сложностями с отладкой. Ты это уже успел прочухать. Создание модулей (так это называется, когда есть вложенные package.json) имеет смысл на практике. Но когда твой проект логически делится на какие-то субъекты. Типа , модуль "заказы", модуль "админка", если речь о беке веб-приложения. А твой не делится. У тебя два разных приложения: бек и фронт.

Плюс разделения тут как минимум в том, что у тебя VSCode не будет с ума сходить, не понимая что именно тут отлаживать и запускать надо. В том, что у тебя могут быть разные версии зависимостей общих (что нормально). Разные системы сборки, даже пакетные менеджеры. Меньше связей избыточных - меньше потенциальных проблем.

Весь мир разработки пляшет от "разделяй и властвуй!". Крупные системы делят на сервисы и микросервисы. Классы разделяют по ответственностям. Функции раскладывают по разным папкам выражающим разные бизнес-задачи. И только ты решил, что в одну кучу всё скидывать - круто и правильно просто потому, что физически возможно и законом не запрещено. Ради бога.

Момент про cd - ерунда какая-то. Открывай каждый проект в своей IDE\терминале и не надо будет никуда "бегать". И отладка будет корректно работать. Не нравится тебе, что часть общих зависимостей дважды копируется в каждый проект забивая твой SSD? Перейди с NPM на YARN. Там вместо пакетов копируются символические ссылки на общий кеш.

А так, я не вижу от тебя весомых аргументов в пользу твоего подхода, кроме того, что "так не запрещено" и "элитарии так не делают, а я буду не как все". Зато проблемы ты со старта получаешь.

Так тебе предметно? Словарный запас устроил?

0

Сообщение от Usaga А зачем тут вообще бегать? Открой ДВЕ VSCode и всё. Это обычная практика.

Просто вкладки раскидываю по всем мониторам из одной VSCode и не грею голову где какое дерево. Особенно удобно когда с Alt+Tab работать приходится.

Сообщение от Usaga Тем, что отладка работает из коробки, как надо. Это не аргумент?

Да вопрос то был - Как отладку сделать.. Пока глючить нечему.
))

Сообщение от Usaga Твой создаёт больше проблем

Хорошо. Перечисли проблемы. Я уже предлагал тебе плюсы перечислить. Давай с проблем. Я только ЗА.
На данный момент у меня нет проблем, может просто из-за того, что более легкой работы не получал.

Сообщение от Usaga типа сложностями с отладкой. Ты это уже успел прочухать.

Нет ещё. Ещё раз. Сложностей НЕТ и НЕ-БЫЛО так как отладку не запускал. Доку (страницу) от VSCOde , которую кинули в начале еще не читал.

Сообщение от Usaga Но когда твой проект логически делится на какие-то субъекты. Типа , модуль "заказы", модуль "админка", если речь о беке веб-приложения. А твой не делится. У тебя два разных приложения: бек и фронт.

Я понимаю к чему это клонишь. твой вариант имеет смысл (имхо) если модули из проекта имеет будущее помимо - когда оказываются в одном контейнере на сервере. А дальше про них все забывают.

Сообщение от Usaga Плюс разделения тут как минимум в том, что у тебя VSCode не будет с ума сходить, не понимая что именно тут отлаживать и запускать надо.

Каждая команда не зависима. Уже говорил Везде есть конфиги с игнорами, которые в частности и обеспечивают независимость.
В репо , в дереве есть игноры + webpack и tsconfig и прочие имеют 'exclude' || 'include'.

Вот твой вариант имеет смысл когда эти модули можно применить в хотелки клиента который объявиться когда-то потом.

Сообщение от Usaga IDE\терминале и не надо будет никуда "бегать".

Не удобно когда с Alt+Tab работать приходится.

Сообщение от Usaga Перейди с NPM на YARN

Всегда работаю на YARN. Но в этом проекте запусти 'husky' , а он не любит YARN. Там сложности с настройкой.

Сообщение от Usaga А так, я не вижу от тебя весомых аргументов в пользу твоего подхода

Как и я в твоём варианте.

Сообщение от Usaga ты со старта получаешь.

Нет ещё проблем в работе. Просто не знаю как впринципе ДЕ-ЛА-ЮТ отладку. Вот когда узнаю, может и появятся проблемы. Пока, отладка это console.log или логи в файл.

Сообщение от Usaga Словарный запас устроил?

Вполне.

0

Сообщение от Usaga А зачем тут вообще бегать? Открой ДВЕ VSCode и всё.

Давай вернем к твоему варианту.

Вот тут задача.
Мой вариант тебе известен. Да и его видно там.

Теперь о конкретике.
На какие проекты сам разделишь?


Вот у меня функции регистрация и добавление заголовка в список дел это лишь директории в sub-проекте - frontend.
Я понимаю, что регистрацию и заголовок и список дел это разные проекты у тебя. Верно или как?

0

Сообщение от Tryd0g0lik На данный момент у меня нет проблем, может просто из-за того, что более легкой работы не получал

Не работающая отладка к проблемам не относится? Публиковать проекты уже пробовал?

Сообщение от Tryd0g0lik Не удобно когда с Alt+Tab работать приходится.

А зачем тебе постоянно между средами переключаться? Будто это нужно по 50 раз в минуту делать.

Сообщение от Tryd0g0lik Вот тут задача. Мой вариант тебе известен. Да и его видно там. Теперь о конкретике. На какие проекты сам разделишь?

На два. Фронт - отдельно, бек - отдельно. Хотя технически, на три. Ещё может корячиться проект миграции базы данных. Ещё сценарии и всякие .env-файлы для docker compose тут вырисовываются, которые я бы в корень всего этого положил.

Я бы ещё рассмотрел вариант разделения образов приложения на две штуки: один релизный (где и фронт и бек) и один dev-образ, который с вотчером будет пересобираться если что-то на фронте или беке поменяется. Мы такое уже применяли на одном проектею. Довольно удобно.

0