Ilya Goncharov

Using Mocha in some build tools (for example Gradle). After Mocha successfully run, I know test status via custom loader. Then I provide test results to "parent" build system and...

@boneskull Thank you for reply. I don't need any result as "passing", I think that in topic starter I incorrectly expressed the thought. Let's imagine we have states: - Tests...

Possibly it is more logical to make similar with DSL structure Something like ``` kotlin.js.?.browser.karma.browsers ``` and for default/main ``` kotlin.js.browser.karma.browsers ``` And another mind, that in KGP we don’t...

Hi, sorry for delay. Basically it is ok for me, but I want to discuss usage of `local.properties`. I am not sure that we support it properly now, and don't...

Could you please consider possibility of usage `org.jetbrains.kotlin.gradle.plugin.PropertiesProvider`. It is entry point to work with gradle properties in our gradle plugin

I think better to remove it support now and use Properties Provider for consistent working with Gradle properties. And in future,`local.properties` support can be just added to `PropertiesProvider`

@mpetuska `PropertiesProvider` supports `local.properties` now, but it can't override `gradle.properties` value, but can add new one. So I think that `PropertiesProvider` can be used freely

Thank you! I'd prefer to use default strategy of `PropertiesProvider` to be consistent with other properties. Do you think it is better to align behavior?

Thank you! I run CI build, and when it is green, I will merge it.

Thanks! Merged it