refactor: New naming of Settings

[jwikman]

This is a proof of concept of how we could refactor the naming of our settings.
The first one out was a boolean setting. Next up is a string setting

Thoughts?

[jwikman]

@theschitz have a look at this to see if this is a plausible way forward?

[theschitz]

Could documentation be it's own class or interface? Having the object grouped and structured similar to package.json would be nice IMO. But is it practical?

[theschitz]

that would mean to access the property it would be like this:

const settings = new Settings("my/workspace/folder");
if (settings.documentation.outputIndexFile) {
     // propably output index file.
}

[jwikman]

I like the idea! 👍

Will play with that later

I think it's a good thing to not rush through this change, so I think this PR will be active some time with some small changes now and then...

[jwikman]

I played a bit with this, and this approach would break the SettingsMap and SettingsLoader logic... :/

  settingsMap.forEach((propertyName, settingName) => {
    const configuredValue = config.get(settingName);
    if (configuredValue !== undefined) {
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
      (settings as any)[propertyName] = configuredValue;
    }
  });

[theschitz]

Of the top of my head and a bit naive perhaps but would this work? We could also rebuild the settingsmap I guess?

 settingsMap.forEach((propertyName, settingName) => {
     // propertyName.split('.')[0] would be "NAB" (?)
     const groupName = propertyName.split('.')[1];
     propertyName = propertyName.split('.')[2];
    const configuredValue = config.get(settingName);
    if (configuredValue !== undefined) {
      (settings as any)[groupName][settingName] = configuredValue;
    }
  });

• edit had a look in the code and updated the vars used.

[jwikman]

You are welcome to test that out! 🙂