Alpha invite for Plugin developers: Bubble Plugin API Version 4

Announcements New features
21

Hey @zelus_pudding, thanks for the question! We had internal discussions about whether to run the Plugin API v4 on Node 16 versus a more modern version than 16. We decided to go with Node 16 since we know that migration to the v4 API is going to require changes for plugins that have server-side actions, so we wanted to introduce a “minimally-breaking” update in v4 to make migration as easy as possible.

The transition from running server side actions on Node 16 to Node 18 is not expected to be nearly as breaking, so when we make this update (this is on our roadmap!) we may not need to rely on a plugin API version to do this.

1 Like
22

Yep, you’re right that context.async isn’t necessary anymore. We included context.async in the v4 API to make migration to the new API a lower lift—people who have code that already uses contex.async will have to make fewer changes this way. The migration to v4 will be required for all plugin authors, so we wanted to design with that in mind so that the migration is as painless as possible.

2 Likes
23

Some more color on the way we’re implementing fetch (@dorilama @vini_brito): We have provided fetch globally which as of the writing this the most up-to-date node-fetch (v3.3.1). We have done this for the following reasons:

  • The latest version of node-fetch is very close in compatibility to the native fetch. This will make the transition to the native fetch more seamless in future plugin api versions.
  • The most recent version of node-fetch is an ESM-only module (you are not able to import it with require()). Rather than add ESM support to plugins at this time, we have exposed the most recent version of node-fetch to plugin authors.

To clarify, we are not using a forked version of node-fetch. We install our dependencies in a separate directory in order to not interact with user-installed packages. Plugin authors are free to install their own version of node-fetch and use that if they wish to.

2 Likes
24

I do understand that it is not required to use the global node fetch, in fact I am advising not to use it and import directly node fetch for the sake of future maintainability.

Of course, except that you can dynamically import it and use it already with the current plugin api and node 14 (see here for an example). In fact I believe your global fetch is actually doing this.

On the day of the announcement the global fetch showed it was importing a package named @bubblegroup/node-fetch, which does not seem to be on the public npm. I suppose it is a fork of node-fetch, but we can’t now because it’s not public.

The point is that your global fetch is opaquely handled by bubble. In a year when you will migrate to node v18 it will be replaced by the standard fetch. If I use it know I will need to test that my client’s plugins will work as expected. If I import directly node-fetch I know that the behaviour will be the same.

At the end of the day I do like that the new api is embracing standard async. I just think this particular choiche around fetch is completely pointless. Yours the castle yours the rules, I guess :man_shrugging:

I appreciate your reply and I cant’t wait to build a couple of plugins that were requiring node >= 16. :grinning:

2 Likes