inlang CLI - collecting requirements and commands

[samuelstroschein]

Problem

Certain tasks benefit from a CLI. Furthermore, the CLI is a core component of enabling CI/CD processes.

Proposal of commands

inlang config

• inlang init interactive config creation command
• inlang config validate validating whether the config is correct.
  An example test is whether a round-trip of readResources and writeResources will lead to changes. If so, that's an error. The test cases could be combined with a general test suite that plugins can use too. The general test suite could strengthen the entire ecosystem by ensuring compatibility.

inlang resources

• inlang resources validate validates whether the resources are correct (do all ids exist, etc. ?)

[samuelstroschein]

inlang init command.

Proposal

Creating the inlang.config.js file can be improved by having an inlang init command that provides an interactive flow for creating the config file.

A few suggestions of what the init command could provide:

• have a one-line npx @inlang/cli init command that does not require an installation of the CLI
• detect what plugin needs to be used (hard one without official plugin API #301 and a registry of plugins)
• on completion, run the config with the upcoming validate config  #309 to verify that everything works

[openscript]

detect what plugin needs to be used

For this a registry of configurations for different tech stacks would be great, containing a suggested config as well as meta data and some logic detecting the tech stack.

[samuelstroschein]

Hardcoding pre-defined configurations for certain stacks could be a good solution to avoid a plugin registry and more. I like it!

[ivanhofer]

I have done a similar approach with npx typesafe-i18n --setup-auto. It is realively easy to detect and works great!

[samuelstroschein]

We can completly automate the process with #408 👀

[ivanhofer]

inlang lint command

This command should call the lint function from the @inlang/core/lint package.
It should output all errors and warnings in the console.
The output should be grouped by resource and message and should display some information how to find the message in the code.
We currently can't really link to the specific line because we don't have something like source maps in place.

If lint errors are found, the process should be exited with an error code so this command can be used in CI.