Как style-loader работает с css-loader?

Question

Я знаю, что style-loader добавляет CSS в dom, вставляя тег.И css-loader получает css в виде строки, когда он встречает require('./style.css');.

Но, как style-loader играет с css-loader ??

Я читаю исходный код style-loader иИсходный код css-загрузчика.Но я не могу понять, как они играют вместе.

Как строка css, которую css-загрузчик получает из style.css, передается style-loader?

Answer 1

Хороший вопрос.Я сделал довольно домашнюю работу, чтобы правильно ответить на нее.Вот что я нашел.

Обычный загрузчик

Общее понимание загрузчиков веб-пакетов состоит в том, что они представляют собой модули, объединенные в цепочку.Каждый загрузчик обрабатывает входной исходный код, преобразует его, а затем передает результат следующему модулю в конвейере.И этот процесс повторяется до тех пор, пока последний модуль не выполнит свою работу.

Но выше - только часть всей картины, верно только для обычных загрузчиков .style-loader не является обычным загрузчиком, поскольку он также имеет метод pitch .

---

Метод pitch Loader

Обратите внимание, что такого не существуетвещь как pitch loader , потому что каждый загрузчик может иметь «нормальную сторону» и «pitch side».

Вот не очень полезный документ веб-пакета о питч-загрузчике .Самая полезная информация - это понятия «фаза основного тона» и «нормальная фаза» и порядок их выполнения.экспорт выглядит так:

module.exports = {}
module.exports.pitch = function loader(request) {
  /* ... */
  return [/* some string */].join('\n')
}

Единственная связанная часть в документе с исходным кодом, указанным выше:

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

До сих пор совершенно неясно, как именно работает эта подача.

Копаем глубже

Я наконец-то наткнулся на это сообщение в блоге (написано на китайском языке) говорит о деталях.В частности, он анализирует точный случай, как в style-loader, где метод pitch возвращает что-то.

Что касается блога, метод pitch в основном используется для доступа и изменения метаданных на ранних этапах процесса загрузчика.,Возвращение из pitch метод действительно редок и плохо документирован.Но когда он возвращает что-то отличное от undefined, вот что происходит:

# Normal execution order is disrupted.
|- style-loader `pitch` # <-- because this guy returns string early
# below steps are all canceled out
  |- css-loader `pitch`
    |- requested module is picked up as a dependency
  |- css-loader normal execution
|- style-loader normal execution

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

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

var content = require("!!./node_modules/css-loader/dist/cjs.js??ref--8-3!./index.css");

Вы заметите, что каждый запрос require полностью настроен с использованием встроенного запроса.Таким образом, этот запрос не будет проходить через test в webpackConfig.module.rules.

Заключение

По сути, это то, что style-loader делает:

1. itзахватывает запрос раньше, выставляя метод pitch.
2. , затем он понимает, о чем этот запрос, читает конфигурацию всех последующих загрузчиков, преобразует всю конфигурацию в inline-queried require(...)
3. затем он выдает новый файл «на лету», и при этом исходный запрос фактически отменяется, а затем заменяется новым запросом к этому файлу в памяти.

Я не знаю ничего лучше, вся правда хранится в исходном коде модуля loader-runner.Если у кого-то есть лучшие источники информации или понимание, пожалуйста, прокомментируйте, оставьте ответ или отредактируйте мой.