Remove existing plugins mechanism in light of v2 modularisation

[lawrence-forooghian]

See this question from a while ago, and @mattheworiordan’s more recent question here.

One thing that I’m not sure about — as things stand, the v2 modular version of the library is only for web. If we were to replace the plugins mechanism with modules, what would that mean for non-web platforms? Would they always come with delta encoding functionality? Or do we need to extend the modules mechanism to other platforms?

[sync-by-unito]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3938

[lawrence-forooghian]

@mattheworiordan @owenpearson I'm going to pick this one up. The thing that's unclear to me is what we do for the default (i.e. non-modular; the one that you get when you import ably as opposed to ably/modules) version of the library. Currently, this version gives you the same functionality that you'd get if you were to create a modular client with all of the available modules. But if we were to introduce a DeltaEncoding module and remove the existing plugins mechanism, this would mean that the default version of the library would now come bundled with delta encoding functionality, increasing its size. Are we OK with that?

[paddybyers]

This is v2, so it's allowed to be incompatible. What about just not supporting deltas with the monolithic version of the library? The plugins mechanism is no longer supported, so if you want to use deltas you have to use the modular library

[lawrence-forooghian]

That'd be an option. Are you okay with that @owenpearson? And how would you like to handle the case where a v2 user tries to use the existing plugins mechanism (e.g. because they didn’t properly read the migration guide or whatever)? Should we detect it so we can give them some useful information (log a warning / throw an error from the constructor)?

[lawrence-forooghian]

Actually, one problem with the approach that @paddybyers suggested is that as things stand, the modular version only exists for the browser; there isn’t a Node one.

[owenpearson]

Yeah that is a problem. If we introduced a modular version for node we would be getting into the world of esm vs commonjs in node which is still a world of pain.

Still, there's nothing stopping us from accepting additional params to the DefaultRest/DefaultRealtime constructors in the same way they're accepted by the base clients, right? ie we could just make it so that...

const Ably = require('ably');
const vcdiffPlugin = require('@ably/vcdiff-decoder');

new Ably.Realtime(options, { vcdiffPlugin });

... works the same way as providing the vcdiffPlugin to ClientOptions.plugins? That way it could be provided to the BaseRealtime/BaseRest classes too even if we don't provide those classes in nodejs?

[paddybyers]

Why not just bundle it in the case of node?

[owenpearson]

yeah me and lawrence were just discussing this on slack - my comment was more focussed on how to support the ClientOptions.plugins functionality in v2 with the new modular api, i'm all for including it in ably-js

[lawrence-forooghian]

Why not just bundle it in the case of node?

Meaning, Node always comes with vcdiff capability? How do you feel about that, @owenpearson — that is, no changes to public API for non-modular version, and if you want vcdiff on web then you have to use the modular version.

[owenpearson]

@paddybyers by bundle it you mean actually include it as part of the core library? I do think import size is usually of little concern for node projects so in that sense it's fine but I do think having that asymmetry of what's included in each platform would be hard to document well

[lawrence-forooghian]

This is the approach that I'm currently taking (included in core library on all platforms except web, and on web you have to use the modular version if you want deltas). I think the documentation will pretty much say what I've just written.

[paddybyers]

Personally I think that's fine, it's the least effort, and consistent with the future direction for modularisation of the browser lib. If in future we decide on a way to modularise the node version, we'd then be able to be fully consistent

[owenpearson]

OK sure, that's fine with me 👍

[lawrence-forooghian]

Done in #1512.