https://kotlinlang.org logo
Join Slack
Powered by
:wave: The `kotlin-js-store/yarn.lock` generated ...
# javascript
b
👋 The 
kotlin-js-store/yarn.lock
generated on my project has the same dependency twice with 2 versions. Not sure if that's expected? It doesn't seem to be a problem, except I'm getting this warning on every single build which is annoying:
Copy code
Transitive npm dependency version clash for compilation "jsmain"
                                  Candidates:
                                        node-fetch@2.7.0
node-fetch@2.6.7
                                  Selected:
                                      node-fetch@2.7.0
Should I just edit manually yarn.lock and keep only the most recent one?
a
Hmm, looks weird. You can do it manually, or you can also try to use 
yarn-deduplicate
tool
b
if that's not expected I'll open an issue then
a
@Ilya Goncharov [JB] is it expected?
c
Do you have multiple JS binaries? If so, maybe it's normal 🤔
b
Hmm not sure what you mean.
c
The lock file is global to the build. If your build has multiple JS binaries, they could have different dependencies and thus there would be multiple versions in the lock file? Not sure though
b
Oh yeah this is on a multi module project
But in fact this issue appeared relatively recently. I think when we upgraded to 2.1.10 but I'll check
c
Have you tried deleting the lock file and rebuilding the project?
b
Yeah it re generates the same
e
What if you temporarily switch to npm? Just to check if the entry is duplicated there too.
b
@Edoardo Luppi With npm the issue is gone indeed, fetch is there only once, with 2.7.0
e
IMO - and if you think it's fast enough - if you're on 2.1.10 I'd probably stay on npm. I recall most issues on that package manager were fixed.
b
Tbh I'm unsure of the implications though :)
m
I also experience similar behaviour since a week. We didn’t have this issue since I started working on the project 4 years ago
👍 2
e
Tbh I'm unsure of the implications though
Good question. That's something to explore I guess. However when it comes down to the final bundles, the result should be the same. Package versions are pinned and thus the pulled npm files should be the same.
Like, at some point you'll have to transition anyway. Yarn Classic is pretty much dead and that's why npm is there now. But I understand if you're not in a good spot to change it, it's obviously something that will impact all developers to some degree.
b
Like, at some point you'll have to transition anyway. Yarn Classic is pretty much dead and that's why npm is there now.
Thanks I didn't know about that!
e
See https://github.com/yarnpkg/yarn?tab=readme-ov-file#%E2%84%B9%EF%B8%8F-important-note Looks like they do the occasional patch, but you can see there are no real updates.
👍 1
(Not saying this shouldn't get fixed btw, since it's still supported)
b
e
Is in 2.0.10 as mentioned in the issue or 2.1.10?
b
woops! Good catch. Wait how come I can't choose 2.1.10 in the list?!
m
For us it happens in 2.1.0 🙂
b
actually this project uses 2.1.0 too - I've updated the issue - thanks @Edoardo Luppi
✔️ 1
e
I wanted to test it out but apparently it requires an ANDROID_HOME directory
b
you mean our project? Yeah it has an android target
e
Last question, before updating to 2.1.0, what was the version? Edit: 2.0.21, found it in the catalog
✅ 1
Btw, Apollo 4.1.1 is importing node-fetch 2.7.0, while Ktor 3.0.0 is importing node-fetch 2.6.7. That's probably why Yarn is now including the two versions, as they are pinned and not in range.
I had to track down transitive deps, but it seems plausible. I don't think it depends on Kotlin
b
I'm not entirely sure how that works. I'm wondering why they are not in range.
e
Copy code
implementation(npm("node-fetch", "2.7.0"))
creates a strict dependency. You need to use npm range notation to allow matching more versions, for example
Copy code
implementation(npm("node-fetch", "^2.6.0"))
b
ahhh! I forgot we had that in Apollo. It all makes sense 👍
e
Backtracking to what I said about Ktor tho. It appears the node-fetch dependency got removed, or at least I can't find it. It does use it but without a dependency. So I'm still missing why 2.6.7 is there in yarn.lock. Must be coming from somewhere else.
b
interesting 👀
e
Ah now I understand it
Well at least there is a mismatch. apollo-kotlin-mockserver 0.1.0 is still referencing 2.6.7. I don't know if it's the cause, but you definitely are using different versions.
So you have
Copy code
apollo = "4.1.1"
...
apollo-mockserver = "com.apollographql.mockserver:apollo-mockserver:0.1.0"
in the catalog
b
ah mockserver depends on ktor 3.0.0
e
mockserver has 2.6.7 in its yarn.lock file. When I blame the lockfile, I see that node-fetch got there with https://github.com/apollographql/apollo-kotlin-mockserver/commit/9269ae693298813d8ebf2f9046fac4798446b968
b
all right mystery solved 🙂 🕵️‍♂️
I guess this must mean that this is expected behavior
e
You can verify all of this by downgrading Apollo to use 2.6.7. The key point is - I think Yarn isn't capable of deduplicating correctly, unlike npm. So @Artem Kobzar’s suggestion to use 
yarn-deduplicate
was indeed correct if you don't want to touch the version under Apollo.
👍 1
b
I'm not completely sure how that yarn.lock file is generated - if it's made manually by the Kotlin plugin I guess it could select the highest version (with a warning maybe) instead of putting both there. But if that's done by invoking some yarn tool then I don't know.
e
No it's not created by KGP. Yarn v1 is run under the hood, and Yarn v1 cannot deduplicate pinned versions
b
all right that makes sense 👍 Thanks for the excellent insights
✔️ 1
never realized: you can't close your own YT issue? 😅
nod 1
e
Btw, you guys switching to npm could give the overall support a push. Since your projects are inherently more complex than the usual samples, there might be issues left to fix, but it's how I imagine the way forward is starting from 2.1.0
b
interesting - honestly I haven't been following this topic too much. Do you know any resources about this?
e
The section you're looking for is https://kotlinlang.org/docs/js-project-setup.html#npm-dependencies
You can also work with npm dependencies directly using the npm package manager instead. To use npm as your package manager, in your gradle.properties file, set the following property:
kotlin.js.yarn=false
But apart from that, I don't think it has been "marketed" too much. The most pressing issue for me was https://youtrack.jetbrains.com/issue/KT-67442, and it's been fixed in 2.1.0
b
any impacts for consumers of the library if we make that change?
e
There shouldn't be. What happens when you ship a 
js()
variant is a 
package.json
is bundled with the 
.klib
You can see that with Ktor's klib here. The klib information is then extracted under 
build/js/packages_imported
as you can see in the screenshot, and referenced in 
build/js/package.json
through the npm 
workspaces
concept. That's what I know about it. Be it Yarn or npm, the resulting 
package.json
file should be no different. However an official response is probably what you want so I'd say wait @Ilya Goncharov [JB] or @Artem Kobzar to answer that.
🙏 1
👀 1
18 Views
Open in Slack
PreviousNext
Powered by