We all know NodeBB plugin is such a pain in the ass, because we do not have type information and we aren't sure about the hooked data structure and made unintended modification and can even unexpectedly corrupt the database. We should move on to use TypeScript, with the added benefit of being able to use ES modules that will make it able to start much faster (since ES modules are static and CommonJS are dynamic, this decreases pressure on module resolution)
@stevefan1999-personal This is probably somewhat of an eventuality, I think.
I don't have much experience with TypeScript, but I know that there are some developers (@PitaJ in particular) who are already writing plugins in TypeScript.
There are a couple of larger tech debt projects to take care of first, but this is definitely already on our medium-term roadmap.
I'm not entirely certain about ESM support; if only because migrating from commonjs to ESM is often an all-or-nothing approach.
IIRC once you are in ESM-land, you can easily import other ES modules, and you can import commonJS modules, but your own exports cannot be imported by commonJS files.
That causes a significant issue in that many plugins (still written in CommonJS) will try to
requireESM-ified libraries in NodeBB and promptly crash.
@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
requireback in ESM.
This even works with ESM plugins by just changing
(await import(libraryPath)).default(and ideally adding some way to resolve
package.jsonsince currently that change needs
plugin.jsonto be defined )
The other way though is the problem - calling
requireon ESM will fail. So the big issue are the
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
requirebefore 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.requirefor most plugins.