I just updated to Kotlin 1.8.0 and started seeing the warning

yarn.lock was changed. Run the kotlinUpgradeYarnLock task to actualize yarn.lock file

.

But I don't really care? This is just some Gradle task that's running indirectly on my behalf, as far as I'm concerned, so I am happy to tell it just to fix itself without bothering me.

Does setting

yarnLockAutoReplace

to true have some dark consequence I'm not aware of?

In Node.js / NPM land, most often dependencies are declared dynamically like "1.9.0 or newer"

If today 1.9.0 is the latest release and your build runs fine, it could be that tomorrow 1.10.0 is released and your build breaks.

Situation isn't different just because you don't depend directly

Thanks, I'll think about it

So I had two followup thoughts after sleeping about it... 1. If yarn dependencies set up by Compose for Web breaks due to poorly set up dynamic dependencies, then even if I lock down the file and fix it for myself, new users will sync my code will crash when they try to run things for the first time in a fresh environment. 2. When I get an error saying that my yarn lock file is out of date, I don't have any choice but to update it myself (since the default behavior in 1.8.0 is to break my compilation with an error). Once upgraded, I'll be broken anyway at that time...

For 1, I suppose I'm supposed to be checking in the .lock file myself? Which .lock file is it? The one in

kotlin-js-store

?

And iirc unless you change dependency declaration e. g. by using a newer compose version, you should consistently use the same versions by having the lock file

That explains why I started seeing it, as I just bumped up my Compose version.

So, it's the yarn.lock file under

kotlin-js-store

I'm guessing?

(When I search for yarn.lock, I get a lot of hits)

The error about calling the lock upgrade task should also have told you the path and to add it to VCS iirc