java.util.zip.ZipException: error in opening zip file (on npm dependency with Kotlin/JS)

[joffrey-bion]

Describe the bug

I have a basic Koltin/JS project with the sockjs-client NPM dependency, and there is a Kotlin file in the main source set defining the Kotlin external declarations for it.

When running ./gradlew clean dokka via Gradle wrapper 6.0, the build fails with an exception:

> Task :krossbow-engine-webstompjs:dokka
WARN: error in opening zip file: /home/travis/build/joffrey-bion/krossbow/build/js/node_modules/sockjs-client/lib/entry.js
java.util.zip.ZipException: error in opening zip file
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:225)
    .......
	at org.jetbrains.dokka.AnalysisEnvironment.createCoreEnvironment(AnalysisEnvironment.kt:89)
	at org.jetbrains.dokka.Utilities.DokkaAnalysisModule.configure(DokkaModules.kt:35)
    .....
	at org.jetbrains.dokka.DokkaGenerator.appendSourceModule(DokkaGenerator.kt:86)
	at org.jetbrains.dokka.DokkaGenerator.generate(DokkaGenerator.kt:41)
	at org.jetbrains.dokka.DokkaBootstrapImpl.generate(DokkaBootstrapImpl.kt:75)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    .....
	at org.jetbrains.dokka.gradle.DokkaTask.generate(DokkaTask.kt:177)

Expected behaviour
The build doesn't throw an exception and the doc is properly generated, ignoring sockjs-client as it doesn't have any documentation.

To Reproduce

I created a simple project that reproduces the issue, but had a hard time getting it to consistently reproduce the issue. The gradle cache sometimes messes with reproduction, I'm not entirely sure why.

You can see the problem in this Travis CI build.

1. Clone the example project: https://github.com/joffrey-bion/dokka-js-experiment
2. Run ./gradlew dokka
3. For subsequent tests, don't forget to clean and delete the .gradle/ folders, because the bug may not show up otherwise

Dokka configuration

This simple basic config allows to reproduce the issue (again, please see example project).

tasks.dokka {
    configuration {
        platform = "js"
    }
}

Installation

• Operating system: macOS (my local machine) and linux (see Travis CI builds), not tested on windows
• Build tool: Gradle v6.0 (using wrapper), I believe 6.0.1 also reproduces the problem
• Dokka version: 0.10.0

Additional context

I had the original issue in the Krossbow project (a personal real-life project). This build reproduces the issue.

The issue was also mentioned in the following Slack thread:
https://kotlinlang.slack.com/archives/C0F4UNJET/p1575545943024600

[sschuberth]

Something very similar seems to happen if the dependency tree of a Kotlin/JVM project contains artifacts of type POM. I'm getting

> Task :reporter:dokka
WARN: error in opening zip file: ~/.gradle/caches/modules-2/files-2.1/org.apache.jena/apache-jena-libs/3.12.0/ae25cd67a7b39cad8d3a3671c5e25f9188506fb8/apache-jena-libs-3.12.0.pom
java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:225)
        at java.util.zip.ZipFile.<init>(ZipFile.java:155)
        at java.util.zip.ZipFile.<init>(ZipFile.java:126)
        at com.intellij.openapi.vfs.impl.ZipHandler$1.createAccessor(ZipHandler.java:45)
        at com.intellij.openapi.vfs.impl.ZipHandler$1.createAccessor(ZipHandler.java:39)
        at com.intellij.util.io.FileAccessorCache.createHandle(FileAccessorCache.java:60)
        at com.intellij.util.io.FileAccessorCache.get(FileAccessorCache.java:52)
        at com.intellij.openapi.vfs.impl.ZipHandler.getCachedZipFileHandle(ZipHandler.java:83)
        at com.intellij.openapi.vfs.impl.ZipHandler.acquireZipHandle(ZipHandler.java:129)
        at com.intellij.openapi.vfs.impl.ZipHandlerBase.createEntriesMap(ZipHandlerBase.java:44)
        at com.intellij.openapi.vfs.impl.ArchiveHandler.getEntriesMap(ArchiveHandler.java:197)
        at com.intellij.openapi.vfs.impl.jar.CoreJarHandler.<init>(CoreJarHandler.java:42)
        at com.intellij.openapi.vfs.impl.jar.CoreJarFileSystem.lambda$new$0(CoreJarFileSystem.java:33)
        at com.intellij.util.containers.ConcurrentFactoryMap$3.create(ConcurrentFactoryMap.java:212)
        at com.intellij.util.containers.ConcurrentFactoryMap.get(ConcurrentFactoryMap.java:59)
        at com.intellij.openapi.vfs.impl.jar.CoreJarFileSystem.findFileByPath(CoreJarFileSystem.java:44)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.findJarRoot(KotlinCoreEnvironment.kt:412)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.contentRootToVirtualFile(KotlinCoreEnvironment.kt:391)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.access$contentRootToVirtualFile(KotlinCoreEnvironment.kt:121)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$6.invoke(KotlinCoreEnvironment.kt:269)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$6.invoke(KotlinCoreEnvironment.kt:121)
        at org.jetbrains.kotlin.cli.jvm.compiler.ClasspathRootsResolver.convertClasspathRoots(ClasspathRootsResolver.kt:70)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:276)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:121)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:513)
        at org.jetbrains.dokka.AnalysisEnvironment.createCoreEnvironment(AnalysisEnvironment.kt:89)
        at org.jetbrains.dokka.Utilities.DokkaAnalysisModule.configure(DokkaModules.kt:35)
        at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223)
        at com.google.inject.spi.Elements.getElements(Elements.java:101)
        at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:133)
        at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:103)
        at com.google.inject.internal.InjectorImpl.createChildInjector(InjectorImpl.java:217)
        at com.google.inject.internal.InjectorImpl.createChildInjector(InjectorImpl.java:224)
        at org.jetbrains.dokka.DokkaGenerator.appendSourceModule(DokkaGenerator.kt:86)
        at org.jetbrains.dokka.DokkaGenerator.generate(DokkaGenerator.kt:41)
        at org.jetbrains.dokka.DokkaBootstrapImpl.generate(DokkaBootstrapImpl.kt:75)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jetbrains.dokka.gradle.DelegatedInvocationHandler.invoke(ProxyUtils.kt:41)
        at com.sun.proxy.$Proxy152.generate(Unknown Source)
        at org.jetbrains.dokka.gradle.DokkaTask.generate(DokkaTask.kt:177)
        ...

when running ./gradlew :reporter:dokka on https://github.com/heremaps/oss-review-toolkit/tree/3f85d301f71daca0e2b38f9c48dec5e7852cf422.

[joffrey-bion]

Any progress on this? This fails on all my Kotlin/JS projects or multiplatform projects as soon as there is an npm dependency involved.

Is there any way to work around it?

[ToxicBakery]

Seems using includeNonPublic = false can help but if you need nonPublic then obviously not so much.

NVM, seems caching sometimes prevents the spam of warnings rather than this being a fix.

[joffrey-bion]

This is still occurring with Dokka 1.4.0 in multiplatform projects apparently:
https://travis-ci.org/github/joffrey-bion/krossbow/builds/725700239#L507

I haven't reproduced in the minimal Kotlin/JS project I mentioned in the initial description of this issue, though.

[drewhannay]

Here's another minimal sample project that reproduces this issue:
https://github.com/drewhannay/dokka-repros/tree/zipFileExceptions

It seems like these exceptions occur if the compile classpath contains anything that isn't a jar / zip file. I traced it to this line in EnvironmentAndFacade.kt which adds everything from the classpath to the analysis environment, regardless of whether it's actually something that can be analyzed.

[willbuck]

I am also experiencing this issue w/ a MultiModule JVM-only build

WARN: error in opening zip file: /home/will/.gradle/caches/modules-2/files-2.1/org.graalvm.truffle/truffle-nfi-native-darwin-amd64/20.2.0/d3ad1011cba788a2b36792ee2ea128b90d5a4f8e/truffle-nfi-native-darwin-amd64-20.2.0.tar.gz
java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:225)
        at java.util.zip.ZipFile.<init>(ZipFile.java:155)
        at java.util.zip.ZipFile.<init>(ZipFile.java:126)
        at com.intellij.openapi.vfs.impl.ZipHandler$1.createAccessor(ZipHandler.java:46)
        at com.intellij.openapi.vfs.impl.ZipHandler$1.createAccessor(ZipHandler.java:39)
        at com.intellij.util.io.FileAccessorCache.createHandle(FileAccessorCache.java:61)
        at com.intellij.util.io.FileAccessorCache.get(FileAccessorCache.java:54)
        at com.intellij.openapi.vfs.impl.ZipHandler.getCachedZipFileHandle(ZipHandler.java:84)
        at com.intellij.openapi.vfs.impl.ZipHandler.acquireZipHandle(ZipHandler.java:131)
        at com.intellij.openapi.vfs.impl.ZipHandlerBase.createEntriesMap(ZipHandlerBase.java:47)
        at com.intellij.openapi.vfs.impl.ArchiveHandler.getEntriesMap(ArchiveHandler.java:184)
        at com.intellij.openapi.vfs.impl.jar.CoreJarHandler.<init>(CoreJarHandler.java:42)
        at com.intellij.openapi.vfs.impl.jar.CoreJarFileSystem.lambda$new$0(CoreJarFileSystem.java:33)
        at com.intellij.util.containers.ConcurrentFactoryMap$2.create(ConcurrentFactoryMap.java:176)
        at com.intellij.util.containers.ConcurrentFactoryMap.get(ConcurrentFactoryMap.java:40)
        at com.intellij.openapi.vfs.impl.jar.CoreJarFileSystem.findFileByPath(CoreJarFileSystem.java:44)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.findJarRoot(KotlinCoreEnvironment.kt:384)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.contentRootToVirtualFile(KotlinCoreEnvironment.kt:363)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.access$contentRootToVirtualFile(KotlinCoreEnvironment.kt:109)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$3.invoke(KotlinCoreEnvironment.kt:206)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$3.invoke(KotlinCoreEnvironment.kt:109)
        at org.jetbrains.kotlin.cli.jvm.compiler.ClasspathRootsResolver.convertClasspathRoots(ClasspathRootsResolver.kt:70)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:213)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:109)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:421)
        at org.jetbrains.dokka.analysis.AnalysisEnvironment.createCoreEnvironment(AnalysisEnvironment.kt:107)
        at org.jetbrains.dokka.analysis.EnvironmentAndFacadeKt.createEnvironmentAndFacade(EnvironmentAndFacade.kt:29)
        at org.jetbrains.dokka.analysis.KotlinAnalysisKt.KotlinAnalysis(KotlinAnalysis.kt:12)
        at org.jetbrains.dokka.base.DokkaBase$defaultKotlinAnalysis$2$1.invoke(DokkaBase.kt:155)
        at org.jetbrains.dokka.base.DokkaBase$defaultKotlinAnalysis$2$1.invoke(DokkaBase.kt:32)
        at org.jetbrains.dokka.plugability.LazyEvaluated.get$core(LazyEvaluated.kt:7)
        at org.jetbrains.dokka.plugability.DokkaContextConfigurationImpl.single(DokkaContext.kt:156)
        at org.jetbrains.dokka.base.DokkaBase$psiToDocumentableTranslator$2$1.invoke(DokkaBase.kt:52)
        at org.jetbrains.dokka.base.DokkaBase$psiToDocumentableTranslator$2$1.invoke(DokkaBase.kt:32)
        at org.jetbrains.dokka.plugability.LazyEvaluated.get$core(LazyEvaluated.kt:7)
        at org.jetbrains.dokka.plugability.DokkaContextConfigurationImpl.actions(DokkaContext.kt:161)
        at org.jetbrains.dokka.plugability.DokkaContextConfigurationImpl.get(DokkaContext.kt:144)
        at org.jetbrains.dokka.DokkaGenerator.translateSources(DokkaGenerator.kt:137)
        at org.jetbrains.dokka.DokkaGenerator.createDocumentationModels(DokkaGenerator.kt:77)
        at org.jetbrains.dokka.DokkaGenerator$generate$1.invoke(DokkaGenerator.kt:30)
        at org.jetbrains.dokka.DokkaGenerator$generate$1.invoke(DokkaGenerator.kt:19)
        at org.jetbrains.dokka.DokkaGeneratorKt.timed(DokkaGenerator.kt:165)
        at org.jetbrains.dokka.DokkaGeneratorKt.access$timed(DokkaGenerator.kt:1)
        at org.jetbrains.dokka.DokkaGenerator.generate(DokkaGenerator.kt:23)
        at org.jetbrains.dokka.DokkaBootstrapImpl.generate(DokkaBootstrapImpl.kt:82)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jetbrains.dokka.gradle.DelegatedInvocationHandler.invoke(automagicTypedProxy.kt:41)
        at com.sun.proxy.$Proxy116.generate(Unknown Source)
        at org.jetbrains.dokka.gradle.AbstractDokkaTask.generateDocumentation$gradle_plugin(AbstractDokkaTask.kt:68)

What's interesting is this only seems to be an issue the first run after a clean, so if I run

./gradlew clean dokkaHtmlMultiModule

I see this issue, but if I then subsequently run

./gradlew dokkaHtmlMultiModule

it usually seems not to be there.

I'm also seeing a fair deal of memory-related issues, like this output when running with the --debug flag on:

2020-11-12T13:10:26.199-0600 [INFO] [org.gradle.launcher.daemon.server.health.LowNonHeapDaemonExpirationStrategy] Expiring Daemon due to JVM Metaspace space being exhausted
2020-11-12T13:10:26.199-0600 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2020-11-12T13:10:26.200-0600 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2020-11-12T13:10:26.200-0600 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2020-11-12T13:10:26.200-0600 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2020-11-12T13:10:26.200-0600 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2020-11-12T13:10:26.201-0600 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2020-11-12T13:10:29.003-0600 [DEBUG] [org.gradle.launcher.daemon.server.DaemonRegistryUpdater] Storing daemon stop event: after running out of JVM memory
2020-11-12T13:10:32.682-0600 [DEBUG] [sun.rmi.transport.tcp] RMI TCP Connection(11)-127.0.0.1: (port 43283) connection closed

Gotten stuck in some loops / locked up daemons that end up being reported as stopped after running out of JVM memory

This is on a box with 64gb of RAM, where I do not otherwise see many / any issues running out of memory.

[willbuck]

Anything any of us out in the user community can do to help resolve this issue? I'd really love to highlight dokka docs for https://github.com/micronaut-projects/micronaut-kotlin/tree/master/kotlin-extension-functions but this is a major thorn in doing so. I will read up on Contributing and see if I can step debug enough to figure out what I'm looking at but I'm afraid debugging gradle tasks is not my area of expertise.

[willbuck]

This warning is definitely still happening on 1.4.30, perhaps it's just related to interplay w/ GraalVM? It isn't blocking completion of the docs task anymore at least!

[wswartzendruber]

For this build script:

https://github.com/wswartzendruber/la4k/blob/04ce710f337965a35743023bc14a7f36bde83099/la4k-winston/build.gradle.kts

Line 47 imports Winston:

implementation(npm("winston", ">=3.0.0"))

Without that import, both gradle clean dokkaHtml and gradle clean build dokkaHtml work.

But when I add it:

wswartzendruber@tower:~/Git/la4k/la4k-winston$ gradle clean dokkaHtml

The Kotlin source set androidAndroidTestRelease was configured but not added to any Kotlin compilation. You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#connecting-source-sets

The Kotlin source set androidAndroidTestRelease was configured but not added to any Kotlin compilation. You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#connecting-source-sets

The Kotlin source set androidAndroidTestRelease was configured but not added to any Kotlin compilation. You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#connecting-source-sets
> Task :la4k-winston:dokkaHtml FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':la4k-winston:dokkaHtml'.
> There was a failure while populating the build operation queue: NPM project resolved without org.jetbrains.kotlin.gradle.targets.js.npm.KotlinNpmResolutionManager@482e6ba0

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 844ms
10 actionable tasks: 2 executed, 8 up-to-date

And if I inject the build task:

wswartzendruber@tower:~/Git/la4k/la4k-winston$ gradle clean build dokkaHtml

The Kotlin source set androidAndroidTestRelease was configured but not added to any Kotlin compilation. You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#connecting-source-sets

The Kotlin source set androidAndroidTestRelease was configured but not added to any Kotlin compilation. You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#connecting-source-sets

The Kotlin source set androidAndroidTestRelease was configured but not added to any Kotlin compilation. You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#connecting-source-sets

> Task :la4k-winston:compileTestKotlinJs
w: /home/wswartzendruber/Git/la4k/la4k-winston/src/test/kotlin/WinstonTests.kt: (96, 17): Variable 'winston' is never used
WARN: zip END header not found: /home/wswartzendruber/Git/la4k/build/js/node_modules/winston/lib/winston.js
java.util.zip.ZipException: zip END header not found
        at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1450)
        at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1458)
        at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1297)
        at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1259)
        at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:707)
        at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:241)
        at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:172)
        at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:186)
        at com.intellij.openapi.vfs.impl.ZipHandler$1.createAccessor(ZipHandler.java:22)
        at com.intellij.openapi.vfs.impl.ZipHandler$1.createAccessor(ZipHandler.java:15)
        at com.intellij.util.io.FileAccessorCache.createHandle(FileAccessorCache.java:45)
        at com.intellij.util.io.FileAccessorCache.get(FileAccessorCache.java:39)
        at com.intellij.openapi.vfs.impl.ZipHandler.acquireZipHandle(ZipHandler.java:46)
        at com.intellij.openapi.vfs.impl.ZipHandlerBase.createEntriesMap(ZipHandlerBase.java:52)
        at com.intellij.openapi.vfs.impl.ArchiveHandler.getEntriesMap(ArchiveHandler.java:181)
        at com.intellij.openapi.vfs.impl.jar.CoreJarHandler.<init>(CoreJarHandler.java:28)
        at com.intellij.openapi.vfs.impl.jar.CoreJarFileSystem.lambda$new$0(CoreJarFileSystem.java:19)
        at com.intellij.util.containers.ConcurrentFactoryMap$2.create(ConcurrentFactoryMap.java:174)
        at com.intellij.util.containers.ConcurrentFactoryMap.get(ConcurrentFactoryMap.java:40)
        at com.intellij.openapi.vfs.impl.jar.CoreJarFileSystem.findFileByPath(CoreJarFileSystem.java:30)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.findJarRoot(KotlinCoreEnvironment.kt:394)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.contentRootToVirtualFile(KotlinCoreEnvironment.kt:373)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.access$contentRootToVirtualFile(KotlinCoreEnvironment.kt:109)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$3.invoke(KotlinCoreEnvironment.kt:213)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$3.invoke(KotlinCoreEnvironment.kt:213)
        at org.jetbrains.kotlin.cli.jvm.compiler.ClasspathRootsResolver.convertClasspathRoots(ClasspathRootsResolver.kt:75)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:221)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:431)
        at org.jetbrains.dokka.analysis.AnalysisEnvironment.createCoreEnvironment(AnalysisEnvironment.kt:106)
        at org.jetbrains.dokka.analysis.EnvironmentAndFacadeKt.createEnvironmentAndFacade(EnvironmentAndFacade.kt:28)
        at org.jetbrains.dokka.analysis.KotlinAnalysisKt.KotlinAnalysis(KotlinAnalysis.kt:13)
        at org.jetbrains.dokka.base.DokkaBase$defaultKotlinAnalysis$2$1.invoke(DokkaBase.kt:175)
        at org.jetbrains.dokka.base.DokkaBase$defaultKotlinAnalysis$2$1.invoke(DokkaBase.kt:35)
        at org.jetbrains.dokka.plugability.LazyEvaluated.get$core(LazyEvaluated.kt:8)
        at org.jetbrains.dokka.plugability.DokkaContextConfigurationImpl.single(DokkaContext.kt:155)
        at org.jetbrains.dokka.base.translators.psi.DefaultPsiToDocumentableTranslator.<init>(DefaultPsiToDocumentableTranslator.kt:66)
        at org.jetbrains.dokka.base.DokkaBase$psiToDocumentableTranslator$2$1.invoke(DokkaBase.kt:58)
        at org.jetbrains.dokka.base.DokkaBase$psiToDocumentableTranslator$2$1.invoke(DokkaBase.kt:35)
        at org.jetbrains.dokka.plugability.LazyEvaluated.get$core(LazyEvaluated.kt:8)
        at org.jetbrains.dokka.plugability.DokkaContextConfigurationImpl.actions(DokkaContext.kt:160)
        at org.jetbrains.dokka.plugability.DokkaContextConfigurationImpl.get(DokkaContext.kt:143)
        at org.jetbrains.dokka.base.generation.SingleModuleGeneration.translateSources(SingleModuleGeneration.kt:103)
        at org.jetbrains.dokka.base.generation.SingleModuleGeneration.access$translateSources(SingleModuleGeneration.kt:21)
        at org.jetbrains.dokka.base.generation.SingleModuleGeneration$createDocumentationModels$1$invokeSuspend$$inlined$parallelMap$1$1.invokeSuspend(parallelCollectionOperations.kt:19)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

> Task :la4k-winston:dokkaHtml FAILED
Initializing plugins
Dokka is performing: documentation for la4k-winston
Validity check
Creating documentation models


FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':la4k-winston:dokkaHtml'.
> KLIB path has unexpected extension: /home/wswartzendruber/Git/la4k/build/js/node_modules/winston/lib/winston.js

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 3s
19 actionable tasks: 13 executed, 6 up-to-date

[joffrey-bion]

Wow, so cool that this is finally fixed. Looking forward to the release! 😄

[joffrey-bion]

Will this fix be part of release 1.6.20? Do you have any ETA for this?

[sschuberth]

See https://github.com/Kotlin/dokka/releases/tag/v1.6.10, it's already part of version 1.6.10.

[wswartzendruber]

See https://github.com/Kotlin/dokka/releases/tag/v1.6.10, it's already part of version 1.6.10.

Yeah, I'm already building a large multiplatform project with it.

[joffrey-bion]

Oh I would have sworn I had tested it on 1.6.10. I guess it was on 1.6.0, my bad.

In any case, thanks! This is great news!