Companion module library versioning

New in this api (compared to Companion 2.x), is the existence of this @companion-module/base and @companion-module/tools libraries.

These are libraries pushing to NPM, and are installed the same way that you can install any other libraries.

Why were they created?

In the past, modules would pull various bits of code from the Companion code. This was problematic as it meant that modules had to live in one of a few specific locations to be able to access the code. In release builds, they had to be built into the release build.
This was the main issue that was blocking being able to support adding newer versions of modules into already released versions.
Additionally, with the new setup of running modules in their own processes, it was very easy for modules to accidentally load in files they werent supposed to and consume too much memory.

Everything that modules were importing before from Companion, is now located inside of @companion-module/base. Some things have not been made available, as they were determined to not be appropriate and alternatives will be recommended to the few module authors who utilised them.

Another benefit of this separation is that it allows us to better isolate modules from being tied to specific versions of Companion. The @companion-module/base acts as a stable barrier between the two. It has intentionally been kept separate from the rest of the Companion code, so that changes made here get an extra level of scrutiny, as we want to guarantee backwards compatability as much as possible.
There were a couple of times during 2.x where a change was made to the module api, that required fixes to be applied to multiple modules. By having this barrier, we hope to avoid that for as long as possible.

What is the purpose of each?

@companion-module/base

This library should be added as a dependency of your module. It contains various helpers and utilities that we think are useful to modules, as well as the main base class that your module should extend.

If you have any suggestions for new utilities or helpers that would benefit many modules, let us know and we shall consider including it.

@companion-module/tools

This library should be added as a devDependency of your module. It contains various bits of tooling and commands that can benefit the development of modules.

For example, it contains a script to bundle your module for distribution and some eslint and typescript config presets that can be used.

We expect every module to use the build script provided from this, the rest is optional extras that you can choose to use if you like.

When should I update them?

@companion-module/base

The version of this library determines the versions of Companion your module can be run with. If you are using a newer version of this than Companion is, then your module is not compatible.

The idea is that a module written for Companion 3.0 will be using 1.4.3 (or earlier, back to 1.0.0 is supported) of this library. And a module writen for Companion 3.1 will be using 1.5 (exact version to be determined nearer release) of this library. The module written for Companion 3.0 will also run in Companion 3.1, but the module written for Companion 3.1 will not work with Companion 3.0.

We recommend targetting the previous stable release of Companion. This will allow users who have not yet updated Companion to use the latest version of your module.
Of course, you may wish to use newer if there are features that your module will benefit from.

@companion-module/tools

This library is less picky about the version, and you will likely benefit by running an up to date version.

Make sure to check the table in the readme to choose the newest version that is compatible with the version of @companion-module/base you are using.