Hello! I just found very weird bug. My Kotlin JS code is different while generating on CI (unix) and...

# javascript

[Rafał Kuźmiński]

Hello! I just found very weird bug. My Kotlin JS code is different while generating on CI (unix) and my local machine. On CI .js file has different size, and generates crash in one very specific situation (one field from Mapbox library is suddenly undefined). Our CI doesn’t contain some custom configuration, it is literally the same code.
I use “frontendBrowserDistribution” task to generate code.
It wasn’t like this till recently, so I had to make some mistake, but I don’t even know where to look. On JVM i would check JDK versions etc, but what can influence Kotlin JS build? Which settings are worth checking? I already tried to clear cache from CI and started all from scratch, it wasn’t it

[Robert Jaros]

Perhaps there are different versions of npm dependencies?

[Artem Kobzar]

Could you show the text of the crash?

[Rafał Kuźmiński]

Crash is

TypeError: Cannot read properties of undefined (reading 'getSource')
    at Map.getSource (presentation.js:102:3642821)"

Where getSource is part of Mapbox library and it checks map.style and then invoking getSource method:

getSource(t) { return this.style.getSource(t) }

[Rafał Kuźmiński]

@Robert Jaros all npm dependencies are defined in gradle, so it cannot see way it to mismatch

[Rafał Kuźmiński]

What is specific, is that Mapbox library itself is not directly setup in project build.gradle. Dependencies look like this:

Project -> Multiplatform library with JS implementation -> Mapbox library via npm

[Robert Jaros]

npm dependencies could be resolved differently if you have yarn.lock in your project on the local machine

[Rafał Kuźmiński]

It is a good call, but I already tried to remove it, and still I got correct result on local machine

[Robert Jaros]

kotlin-js-store/yarn.lock is probably generated on both builders - just compare to be sure they are the same

[Rafał Kuźmiński]

Good idea, I’ll have to add this to artifacts on CI, so it will take my a while, but I’ll test it

[Vampire]

Actually kotlin-js-store/yarn.lock should make sure the same npm lib versions are used everwhere and if a run would produce a different lock file it would even fail, wouldn't it? So I'd really wonder if it is npm library versions, unless the configuration option to always overwrite the yarn.lock is set.

[Rafał Kuźmiński]

I did not set any configuration that would allow to override yarn.lock. But still on CI every build is created separately, so it would generate new yarn.lock

[Robert Jaros]

It could be in .gitignore

[Rafał Kuźmiński]

Well, it is, because in normal development we still use legacy compiler, because it is way faster. Ofc my tests were made with IR compiler on both local and CI

[Rafał Kuźmiński]

And without yarn.lock in gitignore it blocked build after each push/pull

[Vampire]

The yarn.lock is not depening on IR compiler is it?
Having it in gitignore is a bad idea, it exactly voids the sense of it, that the builds everywhere use the same npm lib versions unless you decide to update to the latest versions. 😄

[Rafał Kuźmiński]

I’m sure that yarn.lock is depending on IR compiler, after switching between IR/Legacy we always have to remove yarn.lock
Sure, it voids sens of it, but in my mind (which is mostly affected by JVM world) gradle configuration is enough to make sure that all libraries (npm or otherwise) have correct versions

[Vampire]

Unfortunately it is not, that's why the yarn.lock support is there.
Iirc for the libs you depend on directly it is enough as Gradle uses exactly those versions, but in npm-world it is very common to depend on ranges instead of concrete versions, so you get different version of the transitive dependencies over time and the lock-file prevents that unless you manually decide to update those versions.

It is like depending on version ranges in the JVM world and then not using the Gradle lockfile to make your builds reproducible by not getting new versions over time that might break things.

[Rafał Kuźmiński]

I see. Well you were right, there is a lot of diffs in yarn.lock between CI and my local machine. I have no idea why, because on both it is clean build, without any prior configuration or cache

[Rafał Kuźmiński]

And it was not a case for more than a year now, or at least, diff were not creating errors

[Vampire]

You probably were just lucky for a year 😄

[Rafał Kuźmiński]

Okey, but I still can’t understand why same configuration doesn’t use the same library version, even if it is taken from some range. I literally do those two builds simultaneously, only difference is that one is some unix far away, and other is my laptop

[Rafał Kuźmiński]

I mean, for sure there has to be some difference, but I don’t know where to look for

[Robert Jaros]

I would suspect some cache on your local machine (e.g. https://classic.yarnpkg.com/lang/en/docs/cli/cache/)

[Rafał Kuźmiński]

Adding yarn.lock to git did the trick. Unfortunately it creates a lot of issues with IR/Legacy versions, but it is another subject.
I’ll also make sure to check my local cache, or some hidden cache on CI, because I tested build on new machine, and yarn.lock looks the same like on my machine.

Thank you all @Robert Jaros @Vampire!