Hello! As mentioned in the Kotlin/binary-compatibility-validator#42, the BCV team is not yet ready to accept a contribution for JS/TS support, or even to do due diligence and see if this is a reasonable addition for the future. I’ve created a Gradle plugin that adds support for JS APIs to the KotlinX Binary Compatibility Validator. Originally made for the Fluxo state management framework, now released for general use. • Uses generated TypeScript definitions to do so. • Can be used with any Gradle module with Kotlin/JS target. Either multiplatform or Kotlin/JS. • Will be supported until the official Kotlin/JS support is added to BCV itself. Compatibility tested with: • BCV: 0.8 — 0.13.1 • Kotlin: 1.6.20 — 1.9.0-Beta • Gradle: 7.4+ See how to use it with the JitPack here: https://github.com/fluxo-kt/fluxo-bcv-js#readme Publication on Gradle Plugin Portal is in progress. Please try to use the plugin. I’d appreciate any feedback.

looks good! I like the idea. Using the

d.ts

files is clever and simple. I wonder if something similar could be done for Kotlin/Native projects by using the C headers… Does Fluxo-BCV-JS take the

nonPublicMarkers

into account? I’ve refactored the bcv plugin (and I’m working to try and get the improvements merged upstream). Perhaps we could join forces? https://github.com/adamko-dev/kotlin-binary-compatibility-validator-mu/ It would be nice to have a single plugin that can handle both Kotlin JVM and JS projects I’ll take a look through your code.

@Adam S would be cool to find similar solution for Kotlin/Native and WASM targets. Atm, plugin just copies d.ts files with line endings cleanup and that's it. As it generated by Kotlin. Vision here was to make an addon, not a replacement plugin as it can be hard to merge upstream. But I'm open to any collaboration!

I’m thinking about how to implement

nonPublicMarkers

and the like. I wonder if would be a good idea to convert the .d.ts files to JSON, and then the files might be easier to filter. What do you think?

Also there is a "dukat" that allows to convert d.ts to Kotlin external declarations. Anyway, to do it we need both reading for d.ts files and then writing back after all possible modifications. I'm sure there is something ready for that within NPM ecosystem. At the same time, public JS API is different from regular Kotlin one. Developer can control it more granularly with

@JsExport

annotation. And nothing that can be represented in raw JS will not be exported. So does an additional

nonPublicMarkers

make sense here?