Использование каталога выполнения в качестве файловой базы Gruntfile

Question

Я пытаюсь использовать Grunt для очистки большого проекта. В этом конкретном примере я пытаюсь запустить модульные тесты и хочу сделать это только для путей под текущим grunt каталог выполнения (т. е. результат pwd).

Я хочу один Gruntfile в корне проекта. я знаю grunt найдет и выполнит это без проблем из любого подкаталога. Если я определю параметры своего тестового бегуна, чтобы посмотреть в "test/", он только запускает тесты под {project root/}test/, Есть ли способ сказать Gruntfile уровня проекта, чтобы он указывал свои пути (полностью или частично) относительно места выполнения?

Заметки:

• Мне не нужно говорить: "Зачем ты это делаешь? Грант должен управлять всем твоим проектом!" Это модернизация, и до того дня, когда все это заработает, я хочу / буду нуждаться в этом по частям.
• Повторить, "**/test/" не ответ, потому что я хочу только тесты под текущим grunt исполнительный каталог.
• --base также не будет работать, потому что Grunt будет искать пакеты Node в базовом расположении.
• В аналогичных ситуациях я использовал файл JSON с общей конфигурацией, импортированный с grunt.config.merge(grunt.file.readJSON("../grunt-shared.json"));, Однако для этого требуются файлы Grunt в подпапках, а также жестко заданный путь к файлу общего доступа (например, ../), что кажется незначительным.
• Я мог бы написать код для лазания по каталогам и создания путей, но я бы хотел сделать это в крайнем случае.

Answer 1

Вот решение, которое я придумал (H/T для @firstdoit, /questions/26804146/grunt-poluchit-tekuschuyu-papku-vyizova-a-ne-gruntfile-tekuschuyu-papku/26804154#26804154):

• Создайте один общий файл JavaScript в корне проекта, чтобы централизовать поведение Grunt.
• Каждый "подпроектный" каталог имеет минимальный шаблонный шаблон Gruntfile.js,
• Вручную настройте файловую базу Grunt в общем файле для загрузки с одного node_modules источник.

Gruntfile.js

/**
 * This Gruntfile is largely just to establish a file path base for this
 * directory. In all but the rarest cases, it can simply allow Grunt to
 * "pass-through" to the project-level Gruntfile.
 */
module.exports = function (grunt)
{
    var PATH_TO_ROOT = "../";

    // If customization is needed...
    // grunt.config.init({});
    // grunt.config.merge(require(PATH_TO_ROOT + "grunt-shared.js")(grunt));

    // Otherwise, just use the root...
    grunt.config.init(require(PATH_TO_ROOT + "grunt-shared.js")(grunt));
};

Используя var за PATH_TO_ROOT в основном не требуется, но он предоставляет единую точку фокусировки для использования этого стандартного файла в подпроектах.

{ROOT} /grunt-shared.js

module.exports = function (grunt)
{
    // load needed Node modules
    var path = require("path");

    var processBase = process.cwd();
    var rootBase    = path.dirname(module.filename);

    /*
     * Normally, load-grunt-config also provides the functionality
     * of load-grunt-tasks. However, because of our "root modules"
     * setup, we need the task configurations to happen at a different
     * file base than task (module) loading. We could pass the base
     * for tasks to each task, but it is better to centralize it here.
     *
     * Set the base to the project root, load the modules/tasks, then
     * reset the base and process the configurations.
     *
     * WARNING: This is only compatible with the default base. An explicit base will be lost.
     */
    grunt.file.setBase(rootBase);
    require("load-grunt-tasks")(grunt);

    // Restore file path base.
    grunt.file.setBase(processBase);

    // Read every config file in {rootBase}/grunt/ into Grunt's config.
    var configObj = require("load-grunt-config")(grunt, {
        configPath: path.join(rootBase, "grunt"),
        loadGruntTasks: false
    });

    return configObj;
};