Miguel, muito boa a sua pergunta! Tive que pesquisar e acabei aprendendo também. A melhor resposta que vi:
Em sua essência, webpack é apenas um empacotador de arquivos. Considerando um cenário muito simples (sem divisão de código), isso pode significar apenas as seguintes ações (em um alto nível):
1 - encontre o arquivo de entrada e carregue seu conteúdo na memória
2 - corresponder a determinado texto dentro do conteúdo e avaliá-los (por exemplo, @import)
3 - encontre as dependências com base na avaliação anterior e faça o mesmo com elas
4 - costurá-los todos em um pacote na memória
5 - escreva os resultados no sistema de arquivos
Quando você examina as etapas acima de perto, isso ressoa com o que um compilador Java (ou qualquer compilador) faz. Existem diferenças é claro, mas elas não importam para entender carregadores e plug-ins.
Loaders:
Estão aqui porque o webpack promete agrupar qualquer tipo de arquivo.
Uma vez que o webpack em seu núcleo é capaz apenas de agrupar arquivos js, essa promessa significava que a equipe principal do webpack teve que incorporar fluxos de construção que permitiam que o código externo transformasse um tipo de arquivo específico de uma forma que o webpack pudesse consumir.
Esses códigos externos são chamados de carregadores e normalmente são executados durante as etapas 1 e 3 acima. Portanto, como o estágio em que esses carregadores precisam ser executados é óbvio, eles não exigem ganchos e nem influenciam o processo de construção (já que a construção ou o pacote só acontece na etapa 4).
Portanto, os carregadores preparam o estágio para a compilação e meio que estendem a flexibilidade do compilador do webpack.
Plugins:
Estão aqui porque, embora o webpack não prometa diretamente a saída de variáveis, o mundo quer e o webpack permite.
Como o webpack em seu núcleo é apenas um empacotador e ainda assim passa por várias etapas e subetapas para fazer isso, essas etapas podem ser utilizadas para criar uma funcionalidade adicional.
O processo de construção de produção (minificar e gravar no sistema de arquivos), que é um recurso nativo do compilador webpack, por exemplo, pode ser tratado como uma extensão de sua capacidade principal (que é apenas empacotamento) e pode ser tratado como um plugin nativo. Se eles não tivessem fornecido, outra pessoa o teria feito.
Olhando para o plugin nativo acima, parece que o empacotamento ou compilação do webpack pode ser dividido no processo de empacotamento do núcleo, além de muitos processos de plugin nativos que podemos desligar, personalizar ou estender. Isso significava permitir que código externo se juntasse ao processo de empacotamento em pontos específicos que eles pudessem escolher (chamados de ganchos).
Plugins, portanto, influenciam a saída e meio que estendem a capacidade do compilador webpack.
Essa resposta não nós dá apenas a definição, mas o insight por trás dela.
Valeu!