Can't access /system/plugins.json

[khinsen]

With both v0.26 and v0.26.1, accessing /system/plugins.json returns:

Server TypeError: Cannot read properties of undefined (reading 'require')

The backtrace says:

TypeError: Cannot read properties of undefined (reading 'require')

and points to line 639 in server.js.

[WardCunningham]

This appears to be the code in question:

wiki-server/lib/server.js

Line 639 in 0b41545

const pluginNames = Object.keys(require.main.require('./package').dependencies)

This is an endpoint left over from the Ruby implementation. Plugmatic offers a similar endpoint, so long as Plugmatic is installed. I will offer suggestions later tonight.

      const pluginNames = Object.keys(require.main.require('./package').dependencies)
        .filter(depend => depend.startsWith('wiki-plugin'))
        .map(name => name.slice(12))

[WardCunningham]

This is the preferred endpoint for plugin info. This has a more direct interaction with package management rather than making assumptions about how plugins are organized on a particular install.

http://fed.wiki/plugin/plugmatic/plugins

Curl this into jq to get an idea what is here. First two sections, plugins bundled with the release and those installed by other means, like plugmatic.

curl ... | jq keys
[
  "bundle",
  "install"
]

The old endpoint just listed plugins installed so that could be replaced with:

curl ...   | jq '.install[].plugin'
"zones"
"video"
"transport"
"solo"
"sodoto"
"slide"
"search"
"scatter"
"rss"
"roster"
...

This is the "about" page where we format this information:
http://fed.wiki/about-plugmatic-plugin.html

...

[khinsen]

I use /system/plugins.json to check if plugmatic is available, and as a fallback if it isn't.

What I cannot judge so far is how widespread plugmatic is. If 99% of Wikis have it, there is indeed little point in keeping the old API alive. But then, I propose to remove the API completely. I discovered it by searching for /system in the source code. Probably others will do that as well in the future.

[RalfBarkow]

@khinsen Plugmatic assumes a writable node_modules tree.

[RalfBarkow]

Using Plugmatic as a capability probe therefore conflates two different questions:

1. Can the wiki enumerate plugins?
2. Can the wiki mutate its plugin set at runtime?

For Guix/Nix deployments, the answer is “yes” to (1) and “no by design” to (2).

From that perspective, /system/plugins.json (or an equivalent composition-introspection endpoint) is not a legacy convenience but the only API that correctly reflects how plugins exist in a purely functional deployment. What needs fixing is not the existence of that endpoint, but the current implementation detail that relies on require.main, which breaks under modern ESM entrypoints.

[RalfBarkow]

To make /system/plugins.json safe under an ESM entrypoint, wiki-server should stop using require.main and instead:

• load package.json via a known path (e.g. process.cwd()/package.json), or
• use createRequire(import.meta.url) (if converting file to ESM), or
• pass the needed dependency list in via argv / config, or
• just remove the endpoint (Ward’s direction).

[WardCunningham]

I am in favor of simplifying our core javascript. I see no point in making lots of changes unless we have established a new direction. Since we have now completed a two year conversion away from CoffeeScript, I feel jQuery should be our next target. Simpler is our new direction.