What is the best way to handle the yarn lock? I ad...

# javascript

[Tóth István Zoltán]

What is the best way to handle the yarn lock? I added it to git as that was the advice I've read. However, I run into constant trouble with it. Now Teamcity cannot compile the project because of the lock. I'm thinking about deleting it from git, so it will be re-created every time. Is that a bad idea?

[andylamax]

Yes, its a bad idea to delete yarn.lock

Yarn lock was introduced for a purpose. The tool chain used to break when some incompatible dependency was updated on npm

Just make sure you run ./gradlew kotlinUpgradeYarnLock when you add a new submodule, or a new npm library. And you won't have any problems at all

[Tóth István Zoltán]

Thanks for the info. I did not know that I have to run the upgrade after adding a new module. Though I'm not 100% sure that will solve the problem. I never use npm dependencies, only other Kotlin Multiplatform projects. On the other hand I work on two machines and I see this problem mostly when I switch between the machines (lock was in git). I'll add back the log to git and pay attention to when this happens.

[Vampire]

It's basically the same as when you use dynamic versions for all your normal dependencies. It is not only about breaking builds when dependencies in the registry get an incompatible update, it is also about reproducible builds. With normal dependencies you have Gradle built-in dependency locking to not get different versions when building the same source. The same is the yarn.lock file for npm dependencies.