fix(api) bind extension api entries as facades

[kellymears]

Type of change

• PATCH: bugfix

Dependencies added

• none

Details

As of 5.0.0 our out-of-the-box functions are added to the bud.api container rather than bud itself. instead we bind a facade to bud for each function -- this is what people call in their config files. When a function is called, like bud.entry (any api function), it adds the method name and passed parameters to bud.api.queue. later on this queue is iterated over and the actual functions are called.

The advantage is we remove the need to worry about async operations from user configs. bud.entry is a great example. the actual bud.entry function is async, but the facade we expose is synchronous. everyone wins: we don't block the thread and the user can enjoy the fluent api without worrying about awaiting promises.

Extensions can bind new functions to bud with the api callback. these functions were still being bound directly to bud even after we had moved all the internal config functions to use facades. it works fine until we started to have extensions which had async functions to register. I had kind of hacked a workaround on the register callback for those cases:

export const register: Extension.Module['register'] = async (
  app: Framework,
) => {
  app.api.set('imagemin', imagemin.bind(app)) // add the fn to the bud.api container
  app.api.bindFacade('imagemin') // bind the bud.api entry to bud (as a facade)
}

This change moves that back into the extension controller next...api-bind-facade?expand=1#diff-3749b73842

Changelog

• binds extension api objects/callbacks to bud as bud.api facades
• removes code used to handle this from extensions which were handling it themselves
• adds tests for the bud extensions controller