[Feature] Add config file support for `@kipper/cli`

[Luna-Klatzer]

Is there an existing proposal for this?

• [X] I have searched the existing issues

This feature does not exist in the latest version

• [X] I am using the latest version

Proposal

Add support for a config file that can be read by the Kipper CLI and used to specify project-wide config options that define options such as compile target, warnings, optimisation level etc. (similar to the CLI command line flags & arguments).

The file would have a JSON format and be most likely named kip-config.json or kipper-config.json.

Exact behaviour / changes you want

• [x] Implemented support for reading in config files both automatically and using a built-in API that can be also automatically called. Such a file should be wrapped using a class that can then generate the internal config object which then can passed as an object to a KipperCompile.compile() call.
• [x] Add support for resolving a config file in the current work directory.
• [x] Add support for the basic configuration options also available in the CLI as command line flags & arguments.
• [x] Add support for the following meta-tags:
  • "extends", which specifies a parent config file, where the child should inherit from.
  • "compiler"["version"], which specifies the compiler version of Kipper that should be used for the current project.
  • "resources", which specifies a list of files that are considered resources and should be copied to the build directory using the exact same dir-structure. That means if a file is present in src/public/assets/ then it should be copied to the build directory with the exact same path to avoid path errors in testing/deployment.
• [ ] Add CLI flag --config which can be used to specify a config file not present in the working directory.
• [ ] Add CLI flag --ignore-config/--no-ignore-config, where per default --no-ignore-config is true meaning if a config exists it is loaded. This overwrites the --config flag.

[Luna-Klatzer]

With this issue, a new package called @kipper/config will be introduced in version 0.11.0, which will wrap the load and interpretation behaviour for a Kipper config file. This package will have a flexible structure, meaning that both the config file class and interpreter class can be modified/adjusted depending on the use class (e.g. when being used in the CLI that for example the resources files are loaded into the build folder, which would be unique behaviour to the CLI).

The processing pipeline would look like this:

1. JSON Parsing and loading of file or raw string, which is then wrapped using KipperConfigFile. With the creation of the config file instance the ConfigInterpreter can also be specified.
2. The specified ConfigInterpreter instance verifies that the file is in the correct format (file schema) and performs meta-actions (such as "extend"), as well as ensures the given options are valid (e.g. the target specified even exists or that given resource paths are valid).
3. The ConfigInterpreter "compiles" the file into a fully qualified object, which now contains other than just strings also the correct data structures that are also now internally used, such as the CompileConfig interface from the @kipper/core package. in form of the compileConfig property This compiled output object is now reserved for internal usage and will be passed onto the @kipper/cli or @kipper/core, where the required actions are performed, such as copying all resources files (cli) or modifying the compiler behaviour (core).

This package also will be versioned alongside all other packages, although the file schema will be fully backwards-compatible, meaning that every option once released should be available forever (unless deprecated in favor of another option), so that a config file from example v0.11.0 can be used without changing anything even if updating to newer versions such as 0.12.0 or 0.13.0, or even maybe a jump like 1.0.0.

[Luna-Klatzer]

Should be finished by the first of July! Once this is done we should then move towards focusing on releasing a preview for a stable release and then finishing the first stable release.

[Luna-Klatzer]

Implemented by #519.

[Luna-Klatzer]

The last two goals will be implemented with another issue:

• [ ] Add CLI flag --config which can be used to specify a config file not present in the working directory.
• [ ] Add CLI flag --ignore-config/--no-ignore-config, where per default --no-ignore-config is true meaning if a config exists it is loaded. This overwrites the --config flag.