coder
New code-server installs are broken due to a bad `i18n-next` version
Is there an existing issue for this?
- [x] I have searched the existing issues
OS/Web Information
5 hours ago, the author of a library i18next that is used by code-server published a backward incompatible patch — 25.5.1
https://www.npmjs.com/package/i18next?activeTab=versions
The effect of this is that new installations of code-server will fail to startup with this error —
/Users/user/.version-fox/cache/nodejs/v-22.17.1/nodejs-22.17.1/lib/node_modules/code-server/out/node/i18n/index.js:96
(0, i18next_1.init)({
^
TypeError: (0 , i18next_1.init) is not a function
at Object.<anonymous> (/Users/skanodia/.version-fox/cache/nodejs/v-22.17.1/nodejs-22.17.1/lib/node_modules/@atlassian/code-server/out/node/i18n/index.js:96:20)
at Module._compile (node:internal/modules/cjs/loader:1730:14)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.load (node:internal/modules/cjs/loader:1465:32)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
at node:internal/main/run_main_module:36:49
i18n-next versions of 25.5.0 and below continue to work fine. code-server might want to pin the version of its dependencies.
Steps to Reproduce
1.npm i -g code-server 2. code-server 3.
Expected
Runs fine
Actual
/Users/user/.version-fox/cache/nodejs/v-22.17.1/nodejs-22.17.1/lib/node_modules/@atlassian/code-server/out/node/i18n/index.js:96
(0, i18next_1.init)({
^
TypeError: (0 , i18next_1.init) is not a function
at Object.<anonymous> (/Users/skanodia/.version-fox/cache/nodejs/v-22.17.1/nodejs-22.17.1/lib/node_modules/code-server/out/node/i18n/index.js:96:20)
at Module._compile (node:internal/modules/cjs/loader:1730:14)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.load (node:internal/modules/cjs/loader:1465:32)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
at node:internal/main/run_main_module:36:49
Logs
Screenshot/Video
No response
Does this bug reproduce in native VS Code?
No
Does this bug reproduce in GitHub Codespaces?
No
Are you accessing code-server over a secure context?
- [ ] I am using a secure context.
Notes
No response
Oh strange. We explicitly shrinkwrap our dependencies to prevent issues like this but I guess it must not be working?
Mine is showing 25.3.0 as expected though:
$ npm i [email protected]
$ jq .version node_modules/code-server/node_modules/i18next/package.json
"25.3.0"
I am not sure what could be causing npm to ignore the shrinkwrap, but looks like that might be happening in your case.
Is the shrink wrap respected by npm when installing the dependency globally? If this is like yarn.lock, that would only come into effect when code-server itself is being developed right — not when its being installed by someone else.
My understanding of the shrinkwrap file is that it would always be respected, but I could be misunderstanding the documentation.
The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs
https://docs.npmjs.com/cli/v8/configuring-npm/npm-shrinkwrap-json
I did not try global install but let me do that now in a fresh container:
$ docker run --rm -it node:22 bash
$ apt update && apt install -y build-essential pkg-config python3 jq
$ npm -g i [email protected] --unsafe-perm
...and I keep getting errors about tarballs being corrupted. Only happens when I use -g. Really not sure what is going on...