Make adding Karma plugins easier

[SirDarquan]

angular-librarian uses the 'plugins' property to define the plugins it needs to use for testing. Normally when testing with karma, the system will find anything in the node_modules folder that starts with karma- and make it part of the testing automatically. I think I see the problem you're trying to solve though. If the developer needs a custom plugin, they must add it to this array but if it doesn't exist, it'll require them to know all the pieces ngl uses so they can add a simple plugin.

I'm not sure if you know this but you can set the plugin array to be plugins: ['karma-*'], This would restore the original Karma setup and developers only need to npm install any karma plugin to begin using. If they have a custom plugin, they can still add it to the plugins array and will be merged like normal. Does this make sense? I can elaborate if needed.

[gonzofish]

Yeah, I did know that but I prefer being explicit about what's included in the testing set up. By being explicit, I feel like you remove ambiguity--however, if you think this is a significant issue, perhaps we can allow the custom config to fully override attributes via special attribute naming? So a normal custom config would be something like:

module.exports = {
  plugins: ['my-karma-plugin']
};

But if you want to fully override the attribute (aka, no merge with the preset), you could do:

module.exports = {
  '!plugins': ['karma-*']
};

Think of the leading ! being similar to the CSS !important. This thought is just off-the-cuff, so I'm not sure how easy/viable it is right now

[SirDarquan]

I understand what you're saying and it makes sense. I'm not totally set on the idea of changing it. I was just speaking to the time when I had my karma file setup perfectly before using angular-librarian and then once switching over not quite understanding why it didn't work. Karma itself tries to 'get out of the way' by preferring convention over configuration then angular-librarian says "No, Configuration is king!" I was only trying to help the tool get out of the way of development.

Also, I like the idea of providing a overriding mechanism, but not by changing known properties. I would think the idea is to allow a developer to create a karma config that just works. Tool writers should allow developers to work the way they want to, not force them to work a certain way.

[SirDarquan]

So is this it? Are we not going to continue the discussion? If the ideas I present aren't aligning with your vision of how you believe the library should work, that's fine. But I'd like to know how to move forward and silence doesn't help that.

[gonzofish]

Hey, please don’t think I’m ignoring you—my life has been very busy & chaotic recently. I’ll try to get to this as soon as I can. Sorry.

…

On Sat, Feb 17, 2018 at 10:24 AM SirDarquan ***@***.***> wrote: So is this it? Are we not going to continue the discussion? If the ideas I present aren't aligning with your vision of how you believe the library should work, that's fine. But I'd like to know how to move forward and silence doesn't help that. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYjrmN6B4cAQX1PirfhpG1qOCY44HUYks5tVu8agaJpZM4R4rEg> .

[gonzofish]

I think I can agree to this, I'll remove the plugins section and let users provide the configuration to do it explicitly--good suggestion! I can make this update and I'll close on the next release.