https://kotlinlang.org logo
Join Slack
Powered by
Is there any reason I shouldn't set `yarnLockAutoR...
# javascript
d
Is there any reason I shouldn't set 
yarnLockAutoReplace
to true?
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?
v
Sure, otherwise it wouldn't be there. 😄
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.
d
I see
v
By having a yarn.lock file you pinpoint the exact version to be used on all machines building and also in the future
d
Do I have to worry about that happening given that I'm not using NPM directly myself? I assume it's Compose for Web doing something under the hood for me.
v
🤷
Situation isn't different just because you don't depend directly
d
🫴 🎲
Thanks, I'll think about it
👌 1
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
?
v
Exactly, it's supposed to be checked in and thus lock the versions for anyone running the build
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
d
Ah, I see.
That explains why I started seeing it, as I just bumped up my Compose version.
👌 1
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)
v
Yes
The error about calling the lock upgrade task should also have told you the path and to add it to VCS iirc
d
I only see `yarn.lock was changed. Run the 
kotlinUpgradeYarnLock
task to actualize yarn.lock file` without more information. It would be nice if https://kotlinlang.org/docs/js-project-setup.html#reporting-that-yarn-lock-has-been-updated was fleshed out a bit more with more information about checking in a yarn.lock file.
v
Hm, I thought I've seen it in one of the tasks' outputs. But I probably just have read it in the docs or release notes.
648 Views
Open in Slack
PreviousNext
Powered by