Артем

Ну на самом деле вы придумываете несуществующую ситуацию.

Я бы очень поспорил с этим заявлением.
Достаточно открыть тред недельной давности и посмотреть на споры в комментах между «дублирует» и «не дублирует».
Если бы эти условия были четко прописаны, то никто не спорил.

то это явно претендент на размещение и ни у кого не будет никаких претензий.

Только об этом нигде не написано и узнать об этом можно только из комментариев к этому треду или в техподдержке, о чем я выше и говорил.
Где та грань, при которой «очевидно», а где та, при которой «спорно», а где та, при которой «всего скорее нет»?

Я даже процитирую свои слова, чтобы не повторять это снова.

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

Написать два-три предложения на почту или в телеграм?

Компонент может быть более низкоуровневым и содержать сложную логику, которую в двух-трех предложениях простым языком не опишешь. На первый взгляд компонент может быть «точной копией», а на деле может пересекаться только на условные 20%.

Помимо этого, разработчик может сначала придумать дополнение A, повторяющее функционал уже имеющего на 30%, а затем дополнение B, повторяющее функционал другого компонента на 60%. В таком случае ему придется с каждым дополнением бежать в поддержку и объяснять на пальцах, в чем он повторяет, а в чем нет.
Это неудобно.
Допускаю, что это мое субъективное мнение, но лично я бы этим заниматься не стал.

Сейчас есть список требований к дополнению и пограничные случаи обсуждаются на модерации.

Этот список касается на 99% только оформления, кода и вот этого всего, а про пересекающийся функционал там только 1 строчка, которая не вносит никакой ясности.

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

разработчик приходил с идеей, обсуждали ее с ним и даже с автором дополнения-конкурента

Это же неудобно и очень медленно, не все хотят этим заниматься.
Достаточно сравнить этот вариант с каким-нибудь конкретным списком из N пунктов, где ясно и четко прописано, в каком случае дополнение будет отклонено.

Понятное дело, что все равно будут пограничные спорные случаи, которые придется рассматривать на этапе модерации, но сейчас ясности, на мой взгляд, мало — вопрос выше остался без ответа именно по этой причине.

Я, конечно, уже давно не работаю с MODX, но проходил тут мимо и решил осветить свое видение этой политики со своей колокольни.
На мой взгляд, политика в отношении подобных вещей должна быть кристально ясной и четкой, как два пальца, а не «мы рассматриваем каждое дополнение индивидуально».

Поставьте себя на место разработчика, который хочет написать новое дополнение, но оно пересекается с уже существующим по функциональности. Ему что, идти в поддержку и рассказывать о своих еще не реализованных идеях? Политика должна такие вещи однозначно предусматривать заранее, чтобы разработчик уже знал на 100%, пройдет его дополнение или нет.

Иначе зачем ему вообще тратить свое время, если его дополнение может пройти, а может и не пройти? Это же не лотерея какая-то, а магазин дополнений, у которого, еще раз повторюсь, должны быть однозначные, четкие и понятные правила.

вставить в ресолвер

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

В любом случае, речь здесь идет о том, что это простая задача и она должна быть решена на уровне пакета, а не на уровне «ну как повезет».

Вообще-то build.php только собирает транспортный пакет и при установке пакета (при создании ресурсов) никак не выполняется.

Ты либо между строк читаешь, либо тебе буквально на пальцах все нужно объяснять.
Если второе, то объясняю на пальцах:

• открываешь свой же репозиторий: github.com/touol/loginSetting/blob/c41110e7f8f894dbccd966fc055f351aa3cff4fb/_build/build.php#L689
• выделяешь кусок кода, отвечающий за создание ресурсов, и копируешь
• создаешь резолвер и вставляешь скопированный код
• дописываешь сохранение созданных ресурсов в бд

Достаточно понятно объяснил?
Я уже не говорю о том, что уже есть сотни готовых резолверов в других пакетах, которые делают примерно то же самое.
Так где тут «проблемная задача»?

Новичкам, наверно, полезно самим настроить login, а не через пакет.

Тогда не представляю, кому еще может понадобиться твое творение, если не новичкам.

Это проблемная задача.

Расскажешь, что проблемного в том, чтобы взять кусок кода из build.php, отвечающий за создание ресурсов, и дописать к нему сохранение id хоть в свою таблицу, хоть в системные настройки?

Если хочешь реши ее и всем будет счастье :-)

А больше тебе ничего не нужно сделать?
Я бы понял твое предложение, если бы пакет был полезным/удобным и решал бы какую-нибудь задачу, но у новичков с ним возникнет больше головной боли, чем пользы, поэтому не особо понятно, с чего бы там взяться «счастью».

Вообще тон твоего комментария вызывает впечатление, что тебе лишбы погавкать :-) Извиняюсь конечно за прямоту, но вот такое впечатление у меня.

Тон оформления твоего «пакета» вызывает впечатление, что тебе лишь бы поговнокодить. Извиняюсь, конечно, за прямоту, но вот такое впечатление у меня.

Внимание! страницы создаются с id со 100 по 106. Если у вас на сайте больше 100 страниц, то страницы не создадутся.

Ты это серьезно или пошутить так решил?
Если ты выкладываешь пакет, то будь добр потратить время и соответствующе его оформить, а не вырезать бесполезный кусок кода со своего проекта. Это, как минимум, дурной тон по отношению к пользователям, которые потратят время на твой пакет в попытках завести его у себя.

В чем проблема создать эти ресурсы и сохранить их id динамически, это непосильная задача?
Жаль минус уже поставить нельзя, влепил бы два сразу.

npm выполнены в формате модулей CommonJS

Далеко не все, зависит от пакета. Если пакет пишется под браузер, то он будет юзать ES6 модули, а если под сервер, то там на что фантазии хватит:

• можно юзать CommonJS
• можно юзать ES6 + type: module в package.json
• можно юзать TypeScript или Babel (и даже Webpack при желании), которые будут при билде транспилировать синтаксис ES6 модулей в CommonJS (т.е. своего рода «фейковый» ES6)

В общем-то, CommonJS и настоящий ES6 работают совершенно по-разному, поэтому могу посоветовать почитать об этом, например, тут: redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1

работать с ними в браузере без сборщиков, обработчиков невозможно?

Неправильно, потому что пакеты для фронта никто не пишет на CommonJS модулях, они ж не на ноде работать будут, а в браузере.

но свою функцию не выполняет и текст в консоли браузера не красит.

Конечно, потому что chalk создан для терминала, а не для консоли браузера — это две совершенно разные вещи.
У них же прям первой строкой написано:

Terminal string styling done right

Ну и вроде как это логично, ведь большинство npm пакетов (как я думаю) создаются для nodejs

Естественно, ведь npm — ничто иное, как node package manager.

Другой вопрос в том, что разные пакеты решают разные задачи. Chalk, например, создан для терминала и к фронту (браузеру) не имеет отношения, а условный vue-select, наоборот, не имеет отношения к серверу и должен использоваться исключительно в браузере.

Есть такое деление?

«Деления» нет, есть разные пакеты для разных задач. Просто гуглишь пакет и смотришь, для чего он и где (как) используется.

['moder_pub' => 0, 'class_key:IN' => ['msProduct', 'Ticket']]

говорить о том, что я вам сейчас сайт перепишу, удалю jquery потому что она медленная (чем приведу 85 плагинов в негодность) — ну вообще не вариант.

Абсолютно согласен. В таком случае надо говорить «до свидания».
Ровно как и фирме, в которой ты работаешь. Тебе здесь пишут это уже не первый раз, стоит задуматься)

Или тебе интересно ковырять весь этот говнокод, покрытый пылью и плесенью?

ему сделали сайт 7 лет назад за 1000 рублей и платить за технические работы по нему он не собирается

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

все программные работы для заказчика бесплатны

Повторю еще раз: беги оттуда, да не оглядывайся назад.

где сотни сайтов созданных черте когда и черте на чем, тоже нуждаются в поддержке, переделке и внедрению новых фич

Говорят, что за это нужно платить. Это же нужно заказчику и его бизнесу, а не конкретно тебе. Значит заказчик должен заплатить за свою хотелку. Если его сайт старый и не подлежит адекватной поддержке, значит нужно заплатить за новый сайт. Если не хочет — до свидания.

Уважать себя нужно.

Нигде в этих сайтах не используется vue react или не дай Бог angular.

Правильно, потому что это совсем другой мир разработки.
Тут вопрос личных предпочтений — если тебе интересны CMS и нравится работать на условном битриксе, то естественно, что тебе не нужен ни React, ни Vue, ни Angular.
Но эти сайты никогда не смогут тебе предоставить такой же красивый, динамичный и приятный интерфейс, как условный Vue, например.

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

Вопрос денег? Предположу, что за твою работу не платят хороших денег, потому что она рутинная и не требует особых мозговых усилий. Вероятно, джуниор реакт девелопер может получать не меньше, так в чем проблема стать им, если тебе это интересно?

вам же почему то не хочется писать .json() при работае с fetch хотя это всего7 символов

Потому что это далеко не единственное неудобство в fetch, если бы только это, то хрен с ним.

на это

[...document.querySelectorAll('div')].forEach((el) => {
  el.addEventListener('click', () => alert('hello world'));
});

Ради 1 строки вместо 3 тянуть jQuery?

я просто офигеваю от обилия технологий

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

XMLHttpRequest признан устаревшим и от его использования нужно отказываться.

и

На сегодняшний день не обязательно использовать XMLHttpRequest, так как существует другой, более современный метод fetch.

Совершенно разные вещи. Здесь нет ни слова про «XMLHttpRequest признан устаревшим». Это не более чем рекомендация, потому что в каком-то светлом будущем у нас действительно будет современный и удобный fetch, но это уже совсем другая история.

XMLHttpRequest не может быть признан устаревшим, если для него нет полноценной замены.

что программист может сам решать что ему использовать, и если ему удобно работать с DOM через jquery то пусть работает.

Согласен, но это прямо говорит о том, что программист имеет довольно низкий уровень знаний или не хочет учиться. Повторюсь, что 95% оберток в jQuery запросто переписываются в 1-3 строки на чистом js, поэтому в jQuery нет смысла.
Помимо этого, это вешает на проект тяжелое jQuery-бремя и, вероятно, новый разработчик с более высоким уровнем знаний не захочет браться за старую jQuery лапшу.
Нужно думать не только о «мне так удобно и я так хочу», но и о проекте в целом. Если ты тянешь в проект jQuery, потому что «я так хочу», но на это нет веских оснований, то ты так себе программист.

в одном видео разработчик смешал vue и jquery.

Как я выше сказал — это говнокод в чистом виде, автор видео имеет довольно низкие знания и любой более-менее нормальный разработчик не будет использовать его разработку, если хоть мельком взглянет на то, что там творится.
Автор молодец только в том случае, если к вопросу подходить с точки зрения конечного продукта, а не с технической точки зрения, но мы как раз говорили о технической.

Почему fetch не сможет отправить запрос и вернуть json?

Сможет, только тебе придется писать для него обертку, чтобы удобно работать с api. В реальном приложении ты постоянно обращаешься на разные эндпоинты, конвертишь json и обрабатываешь ошибки, fetch из коробки либо что-то из этого не умеет, либо делает это неудобно. У тебя здесь нет выхода, тебе нужна обертка, либо твое приложение превратится в ад.

Напишешь свою обертку? Во-первых, это будет велосипед, за тебя это уже сделали, и всего скорее лучше. Во-вторых, ты потратишь больше времени и сил на ее тестирование, а вместо этого мог бы писать свое приложение.

Возьмешь готовую обертку над fetch? Ну так и чем это, по-твоему, будет отличаться от axios? При этом, если тебе вдруг понадобится сделать загрузку с процентным прогрессбаром, то ты не сможешь этого сделать на fetch и тебе придется как-то выкручиваться.

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

мне кажется это странные аргументы

Ты, видимо, не понял суть проблемы. Fetch в принципе не поддерживает процентную загрузку, вообще, никак, совсем. Ты не сможешь решить эту проблему оберткой над ним.

Да, над fetch есть обертки, которые тебе и исключение бросят, и .json() за тебя сделают, но процентную загрузку они тебе не дадут без XMLHttpRequest.
Поэтому еще раз повторю, что fetch — низкоуровневый инструмент и пока он не сможет в процентную загрузку, заменить XMLHttpRequest им невозможно.

Я точно также читаю в разных учебниках javascript что объект XMLHttpRequest признан устаревшим и от его использования нужно отказываться.

Можно ссылочку на подобные учебники?
Я бы с удовольствием предложил авторам реализовать загрузку файла с процентным прогрессбаром на современном и новом fetch.

в то время как fetch работает с promise нативно.

Это не меняет ровным счетом ничего, потому что fetch все еще остается неудобным и обрезанным по функциональности, тем более, что обернуть XMLHttpRequest в промис — это несколько строк.

jQuery — устаревшая и ненужная библиотека, потому что:
а) 95% функционала из jQuery — это сахарок, который в современном js не нужен;
б) jQuery-обертки медленные, и это было бы простительно, если бы они были полезные, но это не так;
в) в современном js мире рисуют интерфейсы через React/Vue/Angular, в котором не работают с DOM напрямую. Напомню, что jQuery делает именно это — работает с DOM напрямую. Поэтому скрещивать любой из перечисленных фреймворков и jQuery — это говнокод в чистом виде.
г) для оставшихся 5% функционала из jQuery придуманы отдельные инструменты, куда более удобные, быстрые и функциональные. За примером далеко ходить не надо — тот же axios.

и то и то библиотеки, без которых можно обойтись.

Подскажи, как ты собираешься обойтись без axios, если ты хочешь работать с api в условном Vue?