Reconcile `core.js` exports with `browser.js` and `node.js` exports

[Lucas Werkmeister]

Currently, browser.js and node.js re-export a subset of core.js’s exports: ApiErrors, ApiWarnings and set, but not e.g. DefaultUserAgentWarning or responseBoolean. I think this needs some kind of cleanup. Should they really re-export a subset, and if yes, how much? (I think makeWarnDroppingTruncatedResultWarning is an export that you’d exclude from any reasonable subset, but responseBoolean is arguably almost as useful as set.) Or should they re-export everything, or nothing?

[Lucas Werkmeister]

Hm, I think the idea was that browser.js and node.js export things that make sense for end-users / applications, while the other exports of core.js are things that make sense for libraries that work together with m3api. (I haven’t found a good name for those libraries yet, see #20.) Let’s go through the current exports with that in mind:

• DEFAULT_OPTIONS: Only makes sense for libraries (cf. #21).
• ApiErrors: Makes sense for applications. If they catch an error, they want to be able to check if it’s instanceof ApiErrors.
• ApiWarnings: Makes sense for applications. The warn() handler wants to be able to check if it’s been called with ApiWarnings or another Error subclass.
• DefaultUserAgentWarning: Probably doesn’t make sense for applications? They should just set a user agent and then never expect that warning. (Not sure it makes sense for libraries either, to be honest.)
• Session: Makes no sense for applications.
• makeWarnDroppingTruncatedResultWarning: Makes no sense for applications.
• responseBoolean: Mainly makes sense for libraries – applications should just use formatversion=2.
• set: Makes sense for applications and libraries.

So the current set of re-exports might actually be complete, if we accept this argument. But it should at least be written down somewhere (probably a non-doc comment right above core.js’s exports), so I don’t confuse myself again in the future.