apps property in config to increase clarity

[samuelstroschein]

Should we nest app specific config under apps to declutter the config schema (in the future)?

We have to decide such change now before the vscode extension is released.

export function defineConfig(env) {
  return {
    readResources: "",
    writeResources: "",
    apps: {
      ideExtension: {},
      cli: {},
      editor: {},
    },
    plugins: {},
    lint: {},
  };
}

export function defineConfig2(env) {
  return {
    readResources: "",
    writeResources: "",
    ideExtension: {},
    cli: {},
    plugins: {},
    editor: {},
    lint: {},
  };
}

[samuelstroschein]

@openscript @ivanhofer thoughts? This is a minor issue tbh. But separating core config properties from app specific config, just as we will likely split plugins from core, seems to make sense

[ivanhofer]

Yes, we should definitely split things. But then the next question arises: what is a plugin and what is an app? Do we have a definition for both somewhere?

[samuelstroschein]

Do we have a definition for both somewhere?

Nope.

We should use inlang soon just to define words across inlang in a consistent manner haha

[samuelstroschein]

I was thinking of apps as dedicated programs that can be used on their own, powered by plugins.

[openscript]

Maybe it's a good idea to version the config and offer migration scripts from the CLI.

[samuelstroschein]

No need for a migration for this proposal but in general agree!

[ivanhofer]

Version 2 would be the better approach. It makes it easy to see that something comes from inlang directly and all 3rd-party things would need to use the app property.
If we stick to version 1 then if we decide to add featureX we would need to take care if a 3rd-party app already uses the featureX name. If we would add that, then we would (a) need to use the same config or (b) ignore that implementation and make the 3rd-party app incompatible, which will probably be confusing to a lot of users.