Kotlin 2.0.0.RC1 is pulling in a new set of NPM de...

# eap

[Oliver.O]

Kotlin 2.0.0.RC1 is pulling in a new set of NPM dependencies. Among those, there are new packages without any code like string-width-cjs. There is probably a reason for this, but why?

[turansky]

Looks like transitive dependency

[Oliver.O]

Actually, it is more complex: Take `@isaacs/cliui`:
• Has been renamed from cliui.
• Npm release 8.0.2 has no corresponding version on GitHub.
• Pulled in via jackspeak, glob, karma, ...
• Upgrades "string-width": "^5.1.2", from "^4.2.0",
• Introduces "string-width-cjs": "npm:string-width@^4.2.0",
This may be completely harmless and for a reason (pin CJS modules), but why are people publishing new versions on NPM this way? I'm actually using automated analysis to detect such stuff as it smells like a way to introduce malware.

[Margarita Bobova]

cc @anton.bannykh

[Ilya Goncharov [JB]]

Hi, it looks like transitive dependencies indeed. We can control only first level dependencies, but they can depend on some other packages, and we can’t control it, but they will be part of build and will be presented in lock file. That’s how NPM (or alternative package manager) works.

[Oliver.O]

Yes, I'm aware of that. If every project would carefully vet its direct dependencies, everyone would be fine. Unfortunately, we can't rely on that. The JS ecosystem seems more vulnerable than the JVM one due to the granularity of packages and different levels of awareness. Persisting yarn.lock is a good step to better control supply chain risks, but there is still a need to do some QA before actually upgrading packages. That's where the above came up.

If the NPM registry would require sources published on GitHub and automated reproducible builds running on their platform as a precondition for publishing, that would make us safer. I know it's not there and we don't control their policies. Just wondering: What might be the motivation behind such "direct publishing" without visible changes in the corresponding source code repo?

[Ilya Goncharov [JB]]

Hi, now I don’t see string-width-cjs dependency in yarn.lock , could you please check yours?
If you want to upgrade your lock file, you can remove kotlin-js-store/yarn.lock and run :kotlinStoreYarnLock file or :kotlinUpgradeYarnLock

[Oliver.O]

With Kotlin 2.0.0, a yarn.lock I have re-generated still contains a reference to string-width-cjs, but, as mentioned above, this seems to be an alias which points to (an older version of) string-width.

Relevant sections:

"@isaacs/cliui@^8.0.2":
  version "8.0.2"
  resolved "<https://registry.yarnpkg.com/@isaacs/cliui/-/cliui-8.0.2.tgz#b37667b7bc181c168782259bab42474fbf52b550>"
  integrity sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==
  dependencies:
    string-width "^5.1.2"
    string-width-cjs "npm:string-width@^4.2.0"
    strip-ansi "^7.0.1"
    strip-ansi-cjs "npm:strip-ansi@^6.0.1"
    wrap-ansi "^8.1.0"
    wrap-ansi-cjs "npm:wrap-ansi@^7.0.0"

and:

"string-width-cjs@npm:string-width@^4.2.0", string-width@^4.1.0, string-width@^4.2.0:
  version "4.2.3"
  resolved "<https://registry.yarnpkg.com/string-width/-/string-width-4.2.3.tgz#269c7117d27b05ad2e536830a8ec895ef9c6d010>"
  integrity sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==
  dependencies:
    emoji-regex "^8.0.0"
    is-fullwidth-code-point "^3.0.0"
    strip-ansi "^6.0.1"

string-width@^5.0.1, string-width@^5.1.2:
  version "5.1.2"
  resolved "<https://registry.yarnpkg.com/string-width/-/string-width-5.1.2.tgz#14f8daec6d81e7221d2a357e668cab73bdbca794>"
  integrity sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==
  dependencies:
    eastasianwidth "^0.2.0"
    emoji-regex "^9.2.2"
    strip-ansi "^7.0.1"

[Ilya Goncharov [JB]]

Hi again
As for @isaacs/cliui , it is transitive dependency from following chain
webpack-dev-server -> rimraf -> glob -> jackspeak -> @isaacs/cliui
So answering on the question “why” - that’s it, and it is pretty okay in NPM world.

But I found the problem that Yarn 1 can face with the error during installation of @isaacs/cliui and cliui in the same time because of this
There is workaround for that in case if you faced with errors during installation - https://github.com/isaacs/jackspeak/issues/5#issuecomment-1534321825

Good news that webpack-dev-server has already removed runtime dependency onto rimraf - https://github.com/isaacs/jackspeak/issues/5#issuecomment-1534321825
So on its new release, the new version can be used