The first header was used to include the SpiderMonkey JS API at once,
with safeguards and preprocessor defines. Nowadays, SpiderMonkey
provides modular headers allowing us to include what we use, refs #8086.
Some defines have to be moved to compiler options but it is apparently
a mistake from the SM developers:
https://bugzilla.mozilla.org/show_bug.cgi?id=1987876
Make include-what-you-use happy with files in source/scriptinterface and
fix what needs to be fixed.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
During hotloading the `ScriptRequest` was constructed from a
`JSContext*`. That requires that already an other `ScriptRequest` is
active. Which isn't always the case.
Now The `ScriptRequest` is constructed from a `ScriptInterface&`.
Storing a `ScriptInterface&` in the `ModuleLoader::Result` allows to
remove the `m_Result` as it is retrieved from the `ScriptInterface`.
Not all modules should be able to load all other modules. A predicate
function can to be passed to the `ScriptInterface`. That function
returns whether the module is allowed to loat the module. If no
predicate is passed in no modules can be loaded through that
`ScriptInterface`.
- With modules JavaScript code can be split up into multiple files. We
already implemented such a mechanism (`Engine.LoadLibrary`) in
multiple parts of the engine. The advantage of using modules is
that it's standart (JS-devs are familiar with it) and it doesn't
has to be implemented multiple times.
Note that `Engine.LoadLibrary` loads all files in a directory
while the new `import` only loads one file.
- With modules seemingly global variables are local to that
script/module. We already implemented such a mechanism
(`ScriptInterface::LoadScript`).
