I need this so that I can test my Helm chart

Basically the isCluster setting controls how multiple nodebbs will communicate with each other. If it is not set explicitly it is determined automatically from number of ports used. https://github.com/NodeBB/NodeBB/blob/master/loader.js#L108 So if you are only running a single nodebb process on each server but using multiple servers you need to manually set it to true so that the nodebbs use redis pubsub to communicate. https://github.com/NodeBB/NodeBB/blob/master/src/pubsub.js#L17-L49 If all the nodebb processes are one the same physical server they can just communicate through IPC, if cluster is set to true they will use redis

I have developed a database plugin for NodeBB in the past few months and I want to release it to the public, but before that I want to submit some TS type declarations -- more specifically I manually cherrypicked and observed some type interface, behavior and expected inputs for the database functions, and I want to make sure that NodeBB team would continuously keep track of that in the future so that my plugin can work consistently throughout upgrades. I hope NodeBB team could accept the contribution so that I can release it out to the public ASAP. I have always wanted to extend NodeBB to work on MySQL, MSSQL and Oracle with that plugin.

@julian I think it might be possible with some build tooling magic... Importing plugins using CJS is as you mentioned the easy part - await import() works both ways with CJS, and in a pinch you can use createRequire to get require back in ESM. This even works with ESM plugins by just changing src/plugins/index.js to use (await import(libraryPath)).default (and ideally adding some way to resolve main from package.json since currently that change needs library in plugin.json to be defined ) The other way though is the problem - calling require on ESM will fail. So the big issue are the require.main.require calls. However, I imagine it should be possible to fix that in the build step - though it would require building the server-side code too (which TS will require anyway). I'm not sure how one would go about it with Webpack, but Rollup already has a plugin for converting CommonJS to ESM (since it outputs ESM). I'm not sure how it handles require.main.require, but it probably could be transformed to work correctly as just a relative require before that plugin runs (or the plugin could just be improved to handle that). But ultimately if there are other breaking plugin changes on the roadmap maybe just pairing migration to ESM with them would be simpler. Since importing CJS from ESM mostly works fine, I imagine it would be similar in difficulty to the switch to require.main.require for most plugins.

@stevefan1999-personal Considerations when scaling NodeBB are detailed here: https://docs.nodebb.org/configuring/scaling/ ... but possibly not in the most digestable way. In summary, here's what you need: Redis configured in config.json so it will be used as pubsub and for storing user sessions (volatile data) One of the workers needs isPrimary set to true in config.json, conversely, the other instances need jobsDisabled set to false For socket.io, you will need to make sure to use a ip hashing strategy when routing requests from the load balancer. A typical round-robin style means the socket.io handshake will fail since it ends up hitting different servers.