JS compilation/evaluation APIs are now in #include "js/CompilationAndEvaluation.h"

[Jeff Walden]

It's a long-term SpiderMonkey goal to break up jsapi.h into separate, small headers. jsapi.h is *maybe* convenient in that it's one #include, but that also means compiling SpiderMonkey is super-slow when that file is touched (which is often).

I just took a notable step in that direction, that probably breaks every JSAPI user. :-) Specifically, all main-thread compilation/evaluation APIs are now in "js/CompilationAndEvaluation.h", and the definition of JS::SourceBufferHolder (needed for many compilation APIs) is now in "js/SourceBufferHolder.h" -- and *neither header is #include'd in jsapi.h*.

I didn't change API signatures: existing code should work again after you fix your #includes.

We have no time line for when jsapi.h will be fully broken up, or into what smaller headers it'll be broken. But it's going to keep happening, and when I see *removals* of API from jsapi.h into headers not #include'd within it, such that existing users depending on the one-stop shop will break, I'll try to make a note in mdt.js-engine and mdt.js-engine.internals.

Jeff

[Kent Williams]

JSAPI users are used to things breaking. It's a guarantee you can bank
on: if you use a new version of SpiderMonkey, something will be broken.

That would be fine, except no one is in charge of updating the
documentation when things change. The best guide to embedding
SpiderMonkey is my example on github, and I only got it to work by
pestering Mozilla debs on IRC.

https://github.com/Chaircrusher/SpiderMonkeyES6Example

It's also obsolete mere weeks after putting it on github since the
latest & greatest SpiderMonkey ESR has moved on.

If Mozilla is committed to having third parties embed SpiderMonkey,
making documentations updates a priority would be a great first step.