Закопавшись по уши в sapi/fpm/fpm/fpm_main.c (на участке с 1050 по 1250 строку) я понял, что использование SCRIPT_NAME в качестве значения request_uri у них зачем-то заложено по смыслу.
Осталось получить вразумительный ответ по этому поводу от разработчиков PHP.
Нет, вы неверно поняли.
В моём случае на запрос вида "domain.org/some-path?foo=1" в логи пишется "/index.php?foo=1" если в access.format прописать "%r%Q%q", а если прописать "%{REQUEST_URI}e" — будет "/some-path?foo=1" (что мне и нужно).
И потому вопрос: почему в моём случае "%r" — не "request URI", как сказано в доках, а SCRIPT_NAME (потому что именно он имеет значение "/index.php". При этому как видно по "%{REQUEST_URI}e", данная переменная окружения содержит корректное значение.
Решение, указанное выше, всё-таки не завелось так, как хотелось (при объединении всего в один entry с одновременным использованием output library на выходе получался js, который при подключении возвращал не нужный класс, а webpack-factory). Пришлось пока смириться с лишним js-файлом.
Для интересующихся могу поделиться ссылкой, которая мне сильно помогла: https://stackoverflow.com/a/51858183/9996685
Не знаю пока, чем может аукнуться зависимость extract-loader'а от babel-runtime 6й версии при том, что весь проект использует babel 7, но пока полёт нормальный.
Сергей delphinpro, спасибо за ответ.
Про mini-css-extract-plugin в курсе, но я понял так, что он умеет только собирать подключаемый в js'е css в единый файл. А вот как, имея один js, получить 2 css'а, я пока не смекнул.
Alex, спасибо за ответ.
Мой случай -- это как раз webapp. Но для меня деление имеет значение, так как на стороне gitlab-ci каждый раз с нуля собираются все зависимости. Чем их больше, тем дольше идёт деплой. Часть пакетов нужна именно для разработки (как упомянутый выше bundle-analyzer). Но правильно ли я понимаю, что в моём случае webpack и всё, что нужно для prod-сборки -- это именно dep, а не devDep?
Я понимаю, что тут по большей части семантика, но реально хочется разобраться до конца. Суть вопроса для разработчиков npm-пакетов я уже понял.
В скором будущем появится диздок, написанный непрофессионалом и wireframe'ы, для этого есть люди. Питча нет, так как не задумывались над этим, не желая привлекать инвесторов (проект не для продажи, а питч, в нашем понимании, нужен именно для того, чтобы продать проект). Если бы вы смогли подсказать, где подглядеть грамотный диздок, или как его составить правильно -- буду признателен.
"Если есть хотя бы одностраничный питч, уже можно начинать работать" -- поясните, пожалуйста, что именно даёт питч, почему можно начинать работать, или что именно можно начинать делать?
Оказалось, что PHP-FPM использует в качестве request URI значение SCRIPT_NAME и это так и должно быть. Чудеса, однако.