3.3.1 tarball missing node_modules / fails to start

[tgurr]

3.3.0 tarball https://github.com/requarks/wiki/releases/download/3.3.0/wiki-js.tar.gz: 62.1 MB
3.3.1 tarball https://github.com/requarks/wiki/releases/download/3.3.1/wiki-js.tar.gz: 19.8 MB

resulting in failure on start:

Nov 11 14:03:55 hostname node[945363]: node:internal/modules/package_json_reader:343
Nov 11 14:03:55 hostname node[945363]:   throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
Nov 11 14:03:55 hostname node[945363]:         ^
Nov 11 14:03:55 hostname node[945363]: Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'semver' imported from /var/lib/wiki-js/backend/index.ts
Nov 11 14:03:55 hostname node[945363]:     at Object.getPackageJSONURL (node:internal/modules/package_json_reader:343:9)
Nov 11 14:03:55 hostname node[945363]:     at packageResolve (node:internal/modules/esm/resolve:751:25)
Nov 11 14:03:55 hostname node[945363]:     at moduleResolve (node:internal/modules/esm/resolve:840:18)
Nov 11 14:03:55 hostname node[945363]:     at defaultResolve (node:internal/modules/esm/resolve:973:11)
Nov 11 14:03:55 hostname node[945363]:     at #cachedDefaultResolve (node:internal/modules/esm/loader:708:20)
Nov 11 14:03:55 hostname node[945363]:     at #resolveAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:728:38)
Nov 11 14:03:55 hostname node[945363]:     at ModuleLoader.resolveSync (node:internal/modules/esm/loader:766:56)
Nov 11 14:03:55 hostname node[945363]:     at #resolve (node:internal/modules/esm/loader:690:17)
Nov 11 14:03:55 hostname node[945363]:     at ModuleLoader.getOrCreateModuleJob (node:internal/modules/esm/loader:610:35)
Nov 11 14:03:55 hostname node[945363]:     at ModuleJob.syncLink (node:internal/modules/esm/module_job:277:33) {
Nov 11 14:03:55 hostname node[945363]:   code: 'ERR_MODULE_NOT_FOUND'
Nov 11 14:03:55 hostname node[945363]: }
Nov 11 14:03:55 hostname node[945363]: Node.js v26.13.0
Nov 11 14:03:55 hostname systemd[1]: wiki-js.service: Main process exited, code=exited, status=1/FAILURE
Nov 11 14:03:55 hostname systemd[1]: wiki-js.service: Failed with result 'exit-code'.

[dylanpulver]

This comes from a build change in 3.3.1, not your install. The release workflow stopped running npm ci --omit=dev before packing the tarball (06a55d8), so 3.3.1 ships backend/package.json and package-lock.json with no node_modules. That's the 42 MB difference.

Install the dependencies after extracting:

cd /var/lib/wiki-js/backend
npm ci --omit=dev

Run it as the user the service runs as, then restart the service. The Docker image does the same step during its build (Dockerfile), which is why containers start fine.

I checked it on Node 26.13.0: the extracted 3.3.1 tarball fails with the same Cannot find package 'semver' error, and after npm ci --omit=dev it starts and gets as far as connecting to the database.

[tgurr]

I'd highly request adding either a separate tarball for them and/or provide them as before as this gives great headaches for distribution packaging which requires things to be installed with the package itself instead so we'd have to do some mumbojumbo in the packaging process to fetch these additional requirements. So please reconsider this change and make the release workflow provide a complete tarball again and/or an additional one (which for example the openvas team does for their webinterface with https://github.com/greenbone/gsa/releases/download/v28.7.0/gsa-node-modules-28.7.0.tar.xz in addition to the daemon). Also in a corporate network you might not be allowed to just fetch stuff from the net on the install host.

[dylanpulver]

Fair point, but I'm not a maintainer, so that one is up to @NGPixel. The change looks deliberate (the commit is titled "ci: remove node_modules from build tarball"), so a separate issue asking for a full or node_modules tarball alongside the slim one is probably the best way to get it seen.

[NGPixel]

You need to run npm ci --omit=dev in the ./backend/ folder. The docs were updated with the latest release to say so.

The previous builds included dependencies that were only compatible with linux x64, and even then, it wasn't guaranteed that there wouldn't be compatibility issues with some of the included binaries. Running npm ci ensures the proper binaries are fetched for the target machine. I really don't consider running npm ci to be a chore. It's a very normal step for many applications distributed this way.

If what you're looking for is a simple single step, all batteries included, works on any machine install method, then it already exists and that's containers. If that's not something you want to consider, then you'll have to deal with that extra install step.