Reconcile `core.js` exports with `browser.js` and `node.js` exports
lucaswerkmeister opened this issue · 1 comments
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?
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’sinstanceof ApiErrors
.ApiWarnings
: Makes sense for applications. Thewarn()
handler wants to be able to check if it’s been called withApiWarnings
or anotherError
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 useformatversion=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.