Не перестраивайте пакет webpack, если входные файлы не менялись

У нас есть такая конфигурация webpack, как это:

entry: {
    app: './main.js',
    lib: './vendor.js',   
}

Файл vendor.js состоит только из набора требуемых библиотек из node_modules. 99% времени я строю пучок (ы), выходной пакет lib.js точно такой же.

Могу ли я как-то сказать webpack, что если файл vendor.js не изменился (или, желательно, какое-то другое настраиваемое условие, такое как проверка даты изменения lib.js и package.json, чтобы определить, могу ли я иметь новые версии модулей в node_modules) Я не хочу перестроить пакет lib.js? Для моего сервера CI требуется значительное количество времени из-за typescript переходов и т.д.

ОТВЕТЫ

Ответ 1

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

Однако, если вы действительно почувствовали необходимость сделать это, хотя могли бы, если хотите, чтобы ваш конфигуратор Webpack был динамическим, и используйте fs.stat для чтения vendor.js, а затем добавьте его только как запись, если она изменилась. Что-то примерно такое:

var fs = require('fs');

var config = {
    entry: {
        app: './main.js'
    }
    ...
};

var stats = fs.statSync('./vendor.js');
if (new Date(stats.mtime).getTime() > process.env.LAST_VENDOR_BUILD_TIMESTAMP) {
    config.lib = './vendor.js';
    // Then save new Date().getTime() somewhere like a DB and
    // pass it in as LAST_VENDOR_BUILD_TIMESTAMP on next build.
}

module.exports = config;

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

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