A short summary of the nut.js plugin architecture!

Let's talk about the nut.js plugin architecture!

How plugins are used in nut.js

First of all: nut.js is kind of an "umbrella package"

It orchestrates several other packages, so called "providers", in a way that every single provider does one thing and all the pieces are falling into place.

One provider might be responsible for retrieving screen info like width/height and its current content, while a different provider is responsible to handle keyboard input. Yet another provider might handle on-screen text search or mouse input.

Why are provider plugins a good thing for users?

Every provider is implementing a defined interface.

You can take a look at all currently defined interfaces here

This is a cool thing for several reasons.

1. You can mix and match different providers to fit your needs
2. You can easily build your own providers to fix implementation details without having to wait for a nut.js package release
3. You can wrap existing provider packages

Example

(Artificial) example: You want to avoid at all costs that some script accidentally presses a certain key combination, so you...

• Wrap an existing provider package, e.g. @nut-tree/libnut
• You implement the KeyboardProviderInterface
• Add your own check which keys are to be pressed
• You throw an error if it's the "forbidden key combination"

This way you only have to add an additional import in your script + a call to register the custom provider and you're done. No additional changes to your existing code is needed.

Changing providers

Another huge benefit is that you can easily switch e.g. the underlying OCR engine to perform on-screen text search. nut.js only instruments provider packages via their interfaces, so it does not matter how the provider is implemented, as long as it adheres to the interface.

I hope this sheds some light onto why provider plugins make nut.js really flexible and open for customisation!