You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we have it as a separate task in save-cloud, but we don't have such in save-cli
honestly, I don't understand why we need yarn.lock in save-cli: it doesn't have JS executable artifact, only as a library (and it's a pure kotlin app). Will create an issue for it (if we need the yarn.lock, will create a task for it as in save-cloud),
And still it can fail: even in save-cloud, the task kotlinUpgradeYarnLock is separate and if JS dependency changed by upgrading the kolin (as we see it here) -- it fails
Without a lockfile, yarn/npm will always resolve version ranges each time build is performed. Some time ago, there was an incident when this setup caused all Kotlin installations to download a certain dependency version that contained malware. Since then, having yarn.lock in Kotlin projects is both enabled by default and recommended.
we have it as a separate task in save-cloud, but we don't have such in save-cli
honestly, I don't understand why we need
yarn.lock
insave-cli
: it doesn't have JS executable artifact, only as a library (and it's a pure kotlin app). Will create an issue for it (if we need theyarn.lock
, will create a task for it as insave-cloud
),And still it can fail: even in
save-cloud
, the taskkotlinUpgradeYarnLock
is separate and if JS dependency changed by upgrading the kolin (as we see it here) -- it failsOriginally posted by @nulls in #518 (comment)
The text was updated successfully, but these errors were encountered: