Closed SirDarquan closed 6 years ago
The fallback system is in place and the reduce
code is as well.
After further investigation, none of the changes in this PR moves angular-librarian in the direction of being more robust for developers.What I've found to lead me to this conclusion is that the code in tasks/test.js
happens before any of the code that runs in karma.conf.js
. This means that it's not possible to know if a developer has configured one or more browsers for testing at the point where we're trying to ensure they have at least one. Furthermore, Karma respects all values added to the config
object that is passed to the Karma server, meaning it's not possible to override that value with something from the config file generation.
Now, I completely understand what you're trying to do with the request to ensure PhantomJS is there if no browsers are defined. You want all parts of the system to work in a predictable way and to add conveniences that I developer might have to do. So my question to you is, were you attempting to make such an opinionated library or was the intent to make more of a development tool and it just happens to reflect a really specific workflow? The current workflow requires me to update the tasks/test.js
and karma.conf.js
files for my library to work the way I need it to for a CI server. Naturally, I also have to be aware of changes to those files whenever an angular-librarian update occurs. Maybe my project is the weird one and the workflow you created is what most need. In that case, the work I need to do should be my burden alone.
In any case, I still like the library and would like to help but I'm not sure how to do so with the current constraints. So I believe that this PR should be closed and not reintegrated.
It definitely was intended to be more opinionated, but as flexible as possible. I still think there may be a way to achieve what you're looking for. If I find some time I'll try to implement...but my personally life is (still) a bit hectic right now
fixes #96