karma-runner / karma

Spectacular Test Runner for JavaScript
http://karma-runner.github.io
MIT License
11.96k stars 1.71k forks source link

Allow for different configuration for different instances of the same preprocessor #2058

Open MadaraUchiha opened 8 years ago

MadaraUchiha commented 8 years ago

(This is a feature request, not a bug, but I'll try to match the template as best I can)

Expected behavior

Given a preprocessor 'foo', that is activated for more than one glob like so:

preprocessors: {
  '**/*.a': ['foo'],
  '**/*.b': ['foo']
}

It would be beneficial to be able to pass different configuration for the preprocessor running on .a files, and the one running on .b files.

Actual behavior

You can only pass one configuration object (or at least, that's what the docs + examples I've seen says)

Currently, the only option to do this is if the preprocessor explicitly coded for that ability, and they would need to reimplement Karma's glob expansion and matching, as well as match Karma's precedence rules.

Enviroment Details

        springMessagesPreprocessor: {
            options: {
                suffix: "define([], getMessages );"
            }
        },

As you can see, I can only pass one configuration object that would be called for all runs of the preprocessor, even on different globs.


WDYT? Is this a hassle to implement? I'm willing to give it a shot with a PR (if you tell me ± where to go)

cc @dudabone

dignifiedquire commented 8 years ago

I think this is a good idea, I imagine a syntax like this

preprocessors: {
  '**/*.a': [ { name: 'foo', config: { bar: 1, baz: 1 } }, 'other preprocessor' ],
  '**/*.b': [ { name: 'foo', config: { bar: 2, baz: -1 } }],
}

which would solve the issue of how to associate the config to the preprocessor in question. This should be straightforward to implement, take a look at lib/preprocessor.js for details.

MadaraUchiha commented 8 years ago

Just to make sure I understand it correctly:

Right now, it's the responsibility of the preprocessor to ask the injector for the config based on an arbitrary name the preprocessor defines. This change would require passing the configuration object in, somehow, changing the preprocessor public interface that Karma expects.

Did I miss anything?