support for monorepos / multiple inlang.config.js files

[samuelstroschein]

The inlang.config.js file is required to be in the root of a repository. It would be beneficial if the inlang config file could be placed in a subdirectory as well.

[samuelstroschein]

Workaround #371 (comment)

The alternative is to create one inlang.config.js file that reads messages from multiple modules. In our case the ide-extension and website. Namespace support would be useful but can be "hacked" by prefixing messages with ide-extension.message1234 and website.message2233.

[felixhaeberle]

🎉 The CLI now has a --config option where you can provide your path/to/inlang.config.js.
This makes working with the CLI in monorepos possible and easy!!

Usage

npx inlang lint --config path/to/inlang.config.js

More info in the documentation.

[felixhaeberle]

In every app, we currently have a logic to determine where to look up the inlang.config.js with a default case where we always look in the root / current working directory.

✨ A straightforward solution after/added to this initial check would be to allow for a user-defined location within each app to search for the configuration file.

What makes it hard:

1. you can't store this information because the best place for it to store it would be the inlang.config.js.
2. we could read it from an env variable

CLI solution:

• provide it as path when you execute the commands (no need for saving)
• provide the config path in an env variable

IDE extension:

• provide path in a local vs code setting -> not good for sharing
• provide the config path in an env variable

Editor:

• searches the repository for multiple inlang.config.js and if multiple are found gives select box which inlang env to start.
• add new syntax where the editor can open subfolders like /editor/github.com/inlang/example[/frontend]

[felixhaeberle]

Counter-counter proposal:

We do not even need to write out inlang.config.js in the workspace path. Just provide us with the root.

// inlang.config.js (at the root)

export const defineConfig(env) {
  return { 
     workspaces = [
      "./frontend",
      "./backend"
      ]
  }
}

// nested configs could expose a name 
// to display which workspace is used in apps

export const defineConfig(env) {
  return { 
     name: "frontend"
     // ...
  }
}

[samuelstroschein]

Bad API design.

• the config path is implicit (will require logic that is wasteful and can lead to bugs)
• the config name is now defined in the root config and nested config (leaking responsibilities)
• virtually no benefit at all except writing fewer characters

😘

[felixhaeberle]

@samuelstroschein Oh haha that wasn't intentional with the shared naming!! Corrected it.

---

I don't see the value of providing the inlang.config.js file name. As we can see, npm is also not doing it like this.

virtually no benefit at all except writing fewer characters

High potential of spelling mistakes and duplication.

[samuelstroschein]

I don't see the value of providing the inlang.config.js file name. As we can see, npm is also not doing it like this.

This has been coined as one of the many mistakes that NPM did, see https://youtu.be/M3BM9TB-8yA?t=835.

There is no value of not providing the file you want/

[felixhaeberle]

@samuelstroschein Convinced 🫶

[samuelstroschein]

Has been solved. You can have multiple inlang project files now