Issue #499 - improve Kotlin/JS logger

[scrat98]

Closes #499

[oshai]

The problem with JS IIRC was that there is nodejs and browser that works completely different in the sense of obtaining logger name (maybe there was another use case I don't remember right now).

So the question is how do we test it to make sure we improved both cases.

Also if you can provide more details on the change it will be helpful to review.

[oshai]

I am referring: #279 (comment)

[scrat98]

@oshai

So the question is how do we test it to make sure we improved both cases.

Every use case is covered by test for both JS and WASM. Please, have a look at the SimpleJsTest and SimpleWasmTest headers, there you'll find all use cases that were tested.

val topLevelNamedLogger = KotlinLogging.logger("topLevelNamedLogger")
val topLevelLambdaLogger = KotlinLogging.logger {}

class MyClass {
  val classNamedLogger = KotlinLogging.logger("MyClass")
  val classLambdaLogger = KotlinLogging.logger {}

  // check with non default "Companion" name also
  companion object MyCompanion {
    val companionNamedLogger = KotlinLogging.logger("MyClassCompanion")
    val companionLambdaLogger = KotlinLogging.logger {}
  }
}

You may run these tests with current (master) implementation and find out the tests failure.

Also if you can provide more details on the change it will be helpful to review.

Logger name for both JS and WASM is derived via stack trace analysis to cover all use cases. Currently this is the only way to properly obtain class name for all use cases. Analysis looks like:

1. Find logger invocation line (LOGGER_FUNCTION_NAME). For JS @JSName was added
2. Try to resolve it as a top level property (TOP_LEVEL_INIT_PROPERTIES_REGEX)
3. Try to resolve it as class level property (CLASS_LEVEL_INIT_PROPERTIES_REGEX). Also taking in the consideration Companion object (COMPANION_GET_INSTANCE_SUFFIX)
4. Fallback to the DEFAULT_LOGGER_NAME

Also you can find description here #499

[oshai]

can you change this to an explicit string param with logger name, so it will be clear what was the name?

[scrat98]

It's checking via checkLoggerName(logger: KLogger, expected: String)

[scrat98]

@oshai Hi, could we move this PR forward?

[oshai]

I think the PR is too big at the moment.
I prefer to do smaller changes iteratively (maybe without initial breaking changes).
I am not convinced this will work for both ir/legacy and browser/node (even without talking about wasm).

[scrat98]

@oshai

I think the PR is too big at the moment.
I prefer to do smaller changes iteratively

Do you have any suggestions on how to make it smaller? I couldn't find any obvious options myself. Most of the code lines are tests.

maybe without initial breaking changes

As for the breaking changes, I believe it should be acceptable, since users would need to update the workaround syntax

private val logger by KotlinLogging.logger()

to the idiomatic version

private val logger = KotlinLogging.logger {} 

I am not convinced this will work for both ir/legacy and browser/node (even without talking about wasm).

As mentioned earlier, both the browser and nodejs use cases are covered by the tests. If you don't mind to point out any parts of the code that aren't covered by tests, I’d really appreciate it.

[oshai]

going back to this PR I suggest the following path forward:

• start by applying only the changes in src/jsMain/kotlin/io/github/oshai/kotlinlogging/internal/KLoggerNameResolver.kt with unit tests to check only this class.
• have the CI run those tests in 4 modes - all combinations of: IR/legacy, browser/node.
  later look at other changes in separate pull requests.

[scrat98]

Hello @oshai.

have the CI run those tests in 4 modes - all combinations of: IR/legacy, browser/node.
later look at other changes in separate pull requests.

According to the doc https://kotlinlang.org/docs/js-ir-compiler.html it's not possible to test with Legacy Kotlin compiler.

The old compiler backend has been deprecated since Kotlin 1.8.0. Starting with Kotlin 1.9.0, using compiler types LEGACY or BOTH leads to an error.

https://github.com/oshai/kotlin-logging/blob/master/build.gradle.kts#L37

// kotlin compiler compatibility options
apiVersion.set(KotlinVersion.KOTLIN_2_0)
languageVersion.set(KotlinVersion.KOTLIN_2_0)

Also the tests were already passed on CI for both wasm (browser) and js (browser and node)