ну это больше похоже на художественную литературу:( мне бы техническую все-таки

Парсер HTML используй

@DeepHill https://www.npmjs.com/package/node-html-parser это? Я правильно понял, регулярки не могут покрыть все возможные кейсы? Просто у меня небольшие сниппеты.

Да не могут. Всегда сначала небольшие сниппеты а потом куча проблем. Лучше сразу сделать нормально. Что бы аргументировать почему regexp нельзя использования надо текст писать много мне лень сори)

Понял, спасибо

Мне кажется, что с этим "Лучше сразу сделать нормально" не все так однозначно. Для конкретной задачи, вполне можно обойтись регуляркой и тащить реальный парсер только в том случае, если требования реально поменяются/расширятся. Просто идея о том, что сразу нужно использовать библиотеку или делать типа "future-proof" абстракцию, стало каким-то бичем современной разработки. Мы начинаем добавлять десятки зависимостей и усложнять код уже сейчас, для илюзорной выгоды в будущем, что в большинстве случаев не оправдывается на практике.

В конкретном случае мой опыт говорит обратное ( стоит брать или написать самому парсер )

С опытом, не поспоришь)

Почему можно и  поспорить если есть противоположный /. XML парсер проще и производительней чем regxp для не регулярных выражений коими является HTML/XML. Где-то попадалось такое:
if($i_can_use_xmlParser)
{ //parse xml }
else{ //parse regex }😆

А если ещё и не валидные теги есть или escape... И конечно особенное удовольствие это дебаг регулярок)
«Если у вас есть проблема и вы решили использовать регулярные выражения, у вас уже две проблемы»

Я это писал к тому, что все зависит от конкретной задачи, если человеку нужно просто достать урлы картинок, то для этого не нужен полноценній html parser. Вы бы хоть раз посмотрели код этих парсеров, они там все под капотом регулярки используют)

Парсер будет проще особенно в поддержке потом  насчёт что там под капотом это слишком емкая тема(построение DOM дерева и работа уже с ним )

Главное слово -  "потом")) Может быть потом вам эта функция вообще будет не нужна. Никто не знает, что будет потом. Не забывайте, что устанавливая парсер вы устанавливаете неизвестній код + неизвестный код зависимостей этого парсера в ваш проект и соответсвенно вопрос "поддержки" этого тоже не столь однозначный. Возможно ваш опыт говорит об обратном, поэтому тут глупо спорить. В жизни бывает по-разному)

У автора вопроса УЖЕ  есть проблема с regexp усложнив   регулярку  проблем может стать больше. Использовать апи парсера в разы удобнее. Потом думать может быть уже поздно тех долг слишком высоким может быть "проще выбросить и переписать". Код подключемых либ лучше читать  по возможности и/или использовать пакеты  с высокой репутацией и широкой поддержкой ( код ноды читали ?😜 мало ли что там ) думая автор вопроса услышал аргументов даже больше чем хотел и в состояния сам уже определиться. Костыли всегда вылазит боком но да вс зависит от целей если это одноразовый скрпит и регэксп работает корректно можно и так но тогда не было бы вопроса... А скопировать "заклинание " так себе идея)

всем прив. почему если сделать атоматическую подгрузку статичных файлов , то не выводятся  данные в строке запроса ?
app.use( express.static(__dirname+'/public') );
app.get("/", function(request, response){
   console.log(request.query) // вот здесь ноль реакции
});

Ну видать запрос без параметров. Проверьте в postman том же. Сделайте тестовый запрос

запрос не пустой, вывелся бы пустой объект в таком случае. тут мидлвер вообще не выполняется

app.use( express.static(__dirname+'/public') ); почему-то блокирует все остальные мидлвэры

Не должен по идее

ставлю в конец цепочки , тогда все норм