What's the currently recommended approach with loc...

# webassembly

[CLOVIS]

What's the currently recommended approach with lock files?

I get

* What went wrong:
Execution failed for task ':kotlinWasmStorePackageLock'.
> Lock file was changed. Run the `kotlinWasmUpgradePackageLock` task to actualize lock file

all the time. Sometimes, I have to run kotlinWasmUpgradePackageLock twice for it to disappear. Sometimes, I run tests and then I have to do it again.

How are you dealing with this?

[turansky]

Ignore 😞

[CLOVIS]

fine by me, thanks

[CLOVIS]

Is there a way to set these via gradle properties instead of through convention plugins?

[turansky]

Don't see related properties in the list

[CLOVIS]

Is it enough to apply it only to the root project? That's how it used to work with Yarn

[turansky]

Is it enough to apply it only to the root project?

It's what we do in KFC

[CLOVIS]

perfect, that's easy to set up then, thanks

[CLOVIS]

hm

java.lang.IllegalStateException: :gradle:templates:template-app:jsBrowserTest exited with errors (exit code: 1)
        at org.jetbrains.kotlin.gradle.internal.testing.TCServiceMessagesTestExecutor$execute$1.invoke(TCServiceMessagesTestExecutor.kt:99)
        ... 128 more

[Oliver.O]

Those lock files came into play for a reason. A single one of the large number of Npm micro dependencies taken over by a malicious actor suffices to run malware on your dev machine. I for one do a number of automated and manual checks before accepting changed dependencies.

[Oliver.O]

This was the original incident that triggered the introduction of lock file change reporting: https://blog.jetbrains.com/kotlin/2021/10/important-ua-parser-js-exploit-and-kotlin-js/

[CLOVIS]

Sure, assuming they worked, which is not the case today. I have to refresh them on every build anyway, so they don't protect me from anything.

[Oliver.O]

If
• you are not changing the Kotlin version,
• not changing any of your dependencies, and
• did not delete the lock files under kotlin-js-store,
the lock files still need to be refreshed?

[CLOVIS]

Yes. If I do ./gradlew kotlinWasmUpgradePackageLock and then immediately after ./gradlew check , it sometimes fails with "package lock needs to be refreshed".

[Oliver.O]

Hmm, I've never seen this as far as I remember. If that happens, it defeats the purpose. Could you file a youtrack issue? Even if it does not reproduce consistently, maybe it could help if you'd analyze the diff between lock file contents before and after the second refresh.

[CLOVIS]

I will next time I see it, yeah

[CLOVIS]

There are already a few YT issues for it though

[CLOVIS]

I think this one is the most active: https://youtrack.jetbrains.com/issue/KT-79811/KJS-kotlinUpgradePackageLock-task-is-unreliable

[Oliver.O]

I frequently delete the lock filed before "upgrading" them as suggested here. Maybe you could try that. But I do think that KGP must urgently address that issue and migrate to a stable comparison of dependency versions by diffing only relevant parts of lock file contents. I've upvoted the above ticket.

[chrisjenx]

Oh I found it's a bug, I always run that with --rerun-tasks

[chrisjenx]

there is a Gradle caching bug they haven't fixed yet