One single atuin-tools version

[nyxgear]

I noticed that could become cumbersome to maintain multiple parallel versions of this container.

First, for the container updates that should be spread among all the versions and second because in the future we could have even more Atuin modules for each of which have many versions to be maintained: 2.0.0, 3.0.0, etc.. Unsustainable.

My suggestion would be to keep only a single version of the container capable to handle all the possible Atuin modules. So, the current cms branch functionalities would be included in the master branch by also adding the check for the presence of the app/atuincms module.

Drawbacks

• Checks to be done in the gulp tasks execution to verify Atuin modules presence.
• Minor increase in the gulp tasks complexity

Advantages

• One single atuin-tools version manging all the Atuin modules. Less confusion in atuin-tools utilization into docker-compose.yaml files of Atuin Web Framework projects.
• Easier future updates to the core of atuin-tools. It will no longer be necessary to spread the updates to other versions/branches.

[xcash]

I always agree with a single version to rule them all.
The best solution would be to have a separate configuration to override locally for the inclusion of extra folders and libs.

[nyxgear]

Very well! I will merge the cms branch into the master one also making the necessary adaptations.

What do you mean with "extra folders"? To make aware atuin-tools of other Atuin modules present into the project or to make it manage other static/src-folders? The first case actually could be easly avoided by setting up an autodiscovery procedure in atuin-tools. Instead, in the second case, I think that that would also require to specify the tasks to be performed for the directories and... could become complex and inconvenient to specify those in a config file. I would rather prefer to keep "static" the folders into "static/src" since they already cover all the needs for a web-based project. If any further essential directory into static/src will be required in the future, we can still add the support for it in the atuin-tools tasks.

Beside this, I think we could further investigate for a config file into the static/src/lib folder to specify to atuin-tools how to include the libraries for the project. E.g. avoid to copy unminified files or, the other way around, specify only a list of files to be copied.

[xcash]

I don't like to whitelist specific modules. I prefer an open architecture able to specify the extra libraries to use (aka modules) like cms.
We need to think about a suitable file structure but something like:

static/src/extra/cms/

and in a config file:

extramodules: [
 'cms': {
     js: true,
     ts: true,
     css: true,
     .....
   }
]

something like that...

It's harder to code but more robust and future-proof.

[nyxgear]

I think the location to which place the static files for Atuin's modules is already defined. No need to redefine it.

Right now, the pattern for static folders of Atuin's modules is:
app/<module_name>/static
exactly like the Atuin one is:
app/atuin/static

I agree on the idea to have a configuration file to manage conditional import of single modules' subdirectories and the order with which import them (where applicable).

I like the file structure you suggested however I would place it outside the src folder, since it is more a configuration file related to the whole project and to the Atuin's modules the project uses.
We could place this config file inside the /config folder, exactly where the babel.cfg is now.

What about the file name? config/statics_imports.json? config/extramodules_imports.json?