Documenting build drawbacks processing alephium.config.ts

[simerplaha]

Following PRs #277 & #239, this issue documents the current drawbacks when processing alephium.config.ts.

1. Comments #277

In the following config, the comment value false is set in ralph.json instead of the intended true.

compilerOptions: {
    ignoreUnusedConstantsWarnings: true,
    // ignoreUnusedConstantsWarnings: false,
  },

2. Static values #277

All values are restricted to being static values. Functions or environment variables are not processed.

sourceDir: getDirectory('contracts'),  
compilerOptions: {
  ignoreUnusedConstantsWarnings: someFunction(),
},

3. Parsing #277

As sourceDir is typed incorrectly, without the ending single quote, the entire trailing string is caputured and set into ralph.json's contractPath field, resulting in the following error:

4. Error reporting #277

Although changes are made in alpehium.config.ts, input errors are reported in ralph.json.

5. Learning curve #239

Having two build files (alpehium.config.ts & ralph.json) increases learning curve for developers.

• Some configurations are defined in alpehium.config.ts, that are copied into ralph.json programatically.
• While other LSP specific configurations such as dependencyPath must be defined in ralph.json manually.

This dual configuration approach can lead to confusion, as developers must be aware of which settings belong in which file.

Additionally, implementing library support in issue #44 would also add another configuration in ralph.json:

"dependencies": {
    "web3": "0.38.0",
    "ralph-test": "0.0.0",
    "data-structures": "0.0.0"
  }

6. Introduces Mutation #239

Processing alephium.config.ts introduces mutating the ralph.json file which is client owned. Initial goal was to not introduce code that mutate a file which is owned by the client or any file, as mentioned in this issue "DO NOT introduce code on the server that deletes or overwrites files in the developer's workspace.".