I'm seeing dependabot alerts in a kotlin multiplat...

# javascript

[Adolfo Ochagavía]

I'm seeing dependabot alerts in a kotlin multiplatform project due to the dependencies in kotlin-js-store/yarn.lock. I was surprised when, even after updating to the latest version of kotlin, many alerts were still there. Is that expected? Looking at the generated yarn workspace (in build/js), I see that kotlin automatically adds a bunch of dev dependencies for testing, which in turn result in a lockfile with many outdated dependencies. Maybe the warnings should be ignored, because they usually apply to a web server use case, and not to local testing. Still, I wanted to double-check that the warnings are expected and not a product of some misconfiguration on my end (some of the dev dependencies in the lockfile have had CVEs for years).

[Adolfo Ochagavía]

Btw this is the current list of issues raised by dependabot, which I have manually dismissed

[Edoardo Luppi]

In general terms the release cadence of Kotlin will * never * keep up with npm's library ecosystem. We'd need a new release every week.

[Edoardo Luppi]

So, no mis-config, just the fact Kotlin use npm dependencies that might not be on their latest version.

[Adolfo Ochagavía]

All right, thanks for confirming 🙂

[Adolfo Ochagavía]

I'm currently reviewing the warnings manually and dismissing them with something along the lines of:

These are all dev dependencies, used when running JS tests locally. Attacks based on bad handling of untrusted input (DoS, RCE, etc) are not a concern in this use case.

[Edoardo Luppi]

Something you might want to try is manually bumping dev dependencies via:

implementation(devNpm("package-name", "pinned-version"))

See if everything works.

[Edoardo Luppi]

Obviously, try to stay on the same major version to avoid compatibility issues, if possible.

[Edoardo Luppi]

But in general terms, I tend to agree with you on the fact npm deps should be audited every release.
@Adam Semenenko fyi. @Adolfo Ochagavía could you copy-paste which libraries are getting flagged and which Kotlin version you're using? We can't see your Dependabot security alerts.

[Adolfo Ochagavía]

Ah, sorry about that

[Adolfo Ochagavía]

Here's a gist

[Adolfo Ochagavía]

Thanks for looking into this!

[Adolfo Ochagavía]

The version is 2.3.0 btw (I also included it in the gist title)

[turansky]

> We'd need a new release every week.
It's what convention plugins can/should do without problems 😉

[turansky]

We have such internal plugin in KFC 😉

[Edoardo Luppi]

My 2c on this. And then I'll let the KGP devs jump in if they'd like.
• Move from Yarn to npm (kotlin.js.yarn=false)
• Run npm audit fix manually inside build/js
• Run kotlinUpgradePackageLock again and see what happens. It should copy the updated lockfile under kotlin-js-store.

[Edoardo Luppi]

This is a good reminder that we need a kotlinAuditFixPackageLock task built-in to KGP, to streamline this process.

[turansky]

Did you reported issue?

[Edoardo Luppi]

Nope! I wanted to wait for some other feedback before jumping on YouTrack

[Edoardo Luppi]

I know that there is some work going on in the UX side of things for K/JS and K/Wasm, so it's probably a matter of adding a comment to an existing issue like https://youtrack.jetbrains.com/issue/KT-84782

[Adam Semenenko]

please make that comment @Edoardo Luppi

there is some work going on in the UX side of things for K/JS and K/Wasm

Just to manage expectations: there's no work yet, but we are very aware of the UX issues. Any feedback, suggestions, use-cases are helpful.

[Adam Semenenko]

fwiw in WasmJS outdated dependencies won't trigger these reports. KGP's tooling npm dependencies (e.g. those used to run tests) are installed in a separate location, outside the project, using a lockfile that's bundled into KGP. We're considering also using this approach for JS.

[Edoardo Luppi]

Done, added a comment in KT-84782.

[Adam Semenenko]

thanks @Edoardo Luppi! I have questions about one part you wrote:

A way to extend package-related tasks to execute our own npm operations

could you say more about this? What operations do you mean, and what would are they needed for?

[Edoardo Luppi]

@Adam Semenenko there are a number of commands we might want to execute outside of the normal KGP flow.
https://docs.npmjs.com/cli/v6/commands

Plus, having a base task we can register autonomously is also good workaround if something in KGP stops working, or doesn't exactly do what we want.
Example: npm audit fix also accepts a --force parameter, which SHOULD NOT be passed by KGP by default.

[turansky]

Convention plugin is ready 😉
KFC latest-tools plugin for latest stable versions.