IDE Run Configuration Support

[thanaParis]

As suggested here we are discussing adding IDE-specific support for run configurations in order to make developing for CitrineOS as easy as possible.

@elliot-sabitov has created some support for IntelliJ-specific features. We have other contributors who use VSCode instead. There may be people considering contributing code that use other IDEs as well.

I'd like discussion on:

1. What requires IDE-specific files?
2. Is there a way to provide these things via tools that are not IDE specific, such as maven or gradle?
3. If only IDE-specific code can provide certain valuable functionality, what IDEs should we support to begin with?
4. What should be the approach to adding more supported IDEs in the future? Will we need to use some structure, such as git submodules, to prevent accumulation of many IDE-specific configurations?

[elliot-sabitov]

Run configurations for the common IDEs help run and debug the application:

IntelliJ: https://www.jetbrains.com/help/idea/run-debug-configuration.html#config-folders
VSCode: https://code.visualstudio.com/docs/editor/debugging

What these configurations do is connect the UI in the IDE to trigger the appropriate terminal commands with the correct configurations. In other words, if you are running a Node setup, the IDE has a way for you to be able to easily run the npm commands that you would need to test/run/etc the application as well as attaching breakpoints to the app. These are technology agnostic though, because you can also have these same run configurations to trigger Python, Terraform, Lambdas, Maven, Gradle etc.

The reason it makes sense to include this in the code base is because a developer that utilizes these fundamental tools for their development will most likely create these configurations in their own IDE during setup. Having these available saves dev time since users can hit the ground running quicker.

Ideally we cover a wide range of the most commonly used IDEs that are used by contributors of Citrine.

P.S.

Noting an example run config file for IntelliJ:

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="start:local" type="js.build_tools.npm" nameIsGenerated="true">
    <package-json value="$PROJECT_DIR$/Server/package.json" />
    <command value="run" />
    <scripts>
      <script value="start:local" />
    </scripts>
    <node-interpreter value="project" />
    <envs />
    <method v="2" />
  </configuration>
</component>

you can see that it essentially is an xml that maps to the $PROJECT_DIR$/Server/package.json and calls run start:local, this then shows up in the "Run" section of the IDE showing the running process.

Here is also a VSCode example from the doc above:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "skipFiles": ["<node_internals>/**"],
      "program": "${workspaceFolder}\\app.js"
    }
  ]
}

[majeeel]

I think it's a very good idea to provide standard run configurations. However, we should also bear in mind that these can be changed individually and that you then have to be careful that the changes are not adopted in a PR.

Below is my run config for VSCode as an example (./.vscode/launch.json):

{
    "version": "0.2.0",
    "configurations": [
        {
            "command": "cd Server && npm run start-unix:local",
            "name": "LOCAL",
            "request": "launch",
            "type": "node-terminal",
            "env": {
                "citrineos_data_sequelize_sync": "false",
                "citrineos_util_directus_host": "http://localhost",
                "citrineos_util_directus_port": "8055",
                "citrineos_util_directus_generateFlows": "false",
            }
        },
    ]
}

Currently all VSCode-configurations are ignored via .gitignore:

# Stores VSCode configurations
.vscode

Proposal:
We could ignore the ./.vscode/launch.json, but add a "./.vscode/launch.example.json" to provide an example but also allow for individual configurations without including those in commits.

[elliot-sabitov]

That is a great idea! What if we just had something like launch.json and maybe ignore ./.vscode/*local.json or something similar to allow individual "local" configurations

[ChrisWeissmann]

@elliot-sabitov I think @majeeel 's idea would work better with newcomers. For ignoring *local you have to know this pattern. But the other way around, we only include *.example.json which allows for users to do what ever they want locally. Basically it's either we whitelist or we blacklist changes. I would argue whitelisting leads to tighter control on what goes on in that folder.

[elliot-sabitov]

yeah either way is fine with me