Vscode debug configuration

[Hoxolotl]

added launch file to enable debugging with vscode as documented on electron documentation
The "Main + renderer" option will appear when you select "Run and Debug" from the sidebar, allowing you to set breakpoints and inspect all the variables among other things in both the main and renderer processes.

[Potherca]

I am very strongly opposed to including IDE or editor specific files to any project. The main reasons for this are:

1. A project that starts adding things for one tool, will soon have to allow files for other tools. This becomes a sliding slope as there is no metric where to draw a new line once the line has been crossed to allow add non-project files.
2. All files in a project require maintenance. But for non-project files this means that, instead of a developer wasting their own time on things that help them, a project is asked to waste time on things that don't help the project.
3. A developer might already have IDE/editor specific configurations in their .vscode folder. By also having files for such things in the project, sooner or later, conflicts will occur. Developer frustration and unexpected behavior can be avoided simply by not adding such files.
4. I prefer documentation / educating developers over ready-made solutions added to a project.

As an alternative to this MR, I would like to propose #3

[Hoxolotl]

1 . Hypothetically in a project with cmake and sconscript (or pakcage.json) files I would have to reconfigure those from scratch? Just to clarify in this specific case the context of developing electron apps the launch.json file IS a project file as far as I'm concerned.

2 . so instead of maintaining a file, we'll have to maintain a readme, which in it, contains the code, that would be in the file? - fine by me.

3. Developer frustration is unavoidable. In this case it's either because he/she has to figure out how to set up the debugger, or because the debugger is overwriting settings. In this case I would prefer a junior developer have config files to start with, than a senior developer having his/her config broken: I expect the senior developer to be able to troubleshoot, I don't want to scare off the junior with a wall of text and explanations.

4. people don't read, developers included, adding friction to ensure they read the documentation supposes the documentation is good enough to fill in the blanks in their knowledge, I can't read minds to know where those blanks are.

I'd agree to #3 but I'd like to keep a branch I can use to put the .vscode folder in, this will also make sure we have a configuration file to point to in case developers use the same IDE with different configurations and issues crop up.

[Potherca]

Regarding point 1. My view is geared more towards needing to add a .jetbrain folder, a .netbeans folder, a .vi, .emacs, .joe, etc. It is not a project file, it is a developer-specific file, as each developer will choose a (in this case) debugging process that is specific to them based on the tools they prefer. Unless we force all contributors to this project to use VS Code. It is for the same reason that we don't want IDE specific entries in our .gitignore file.

Regarding 2. Ideally, we only link to the documentation where the JSON is already specifically stated. The JSON in the doc is added as a favor to the author (who would then indeed be expected to keep the docs up to date, as he would the file). My personal preference would be to not add it as a file or in docs, but only maintain the correct link to existing docs.

Regarding 3. Your point is valid. I agree with leaning more towards onboarding more junior developers in the scope of decision-making. That said, I have seen similar situations (specifically once more IDE specific code is added) that break for more junior developers as well as seniors.

Regarding 4, The assumption is that people will have to read documentation, otherwise there is no point in contributing... If things are documented, at least there is "something" to point to when trying to help people along. When people experience gaps (assuming they report their findings), more docs will need to be added. However, it will be hard to find a balance between filling in most gaps without creating a wall of text and explanations.

I think that is the main point for all concerns I raised. Documentation is an ongoing process, the hard part is finding which balance to strike when and where in a projects' lifecycle.

For PDS Interop, an attempt was made to solve this issue by creating a CONTRIBUTING.md for the entire organization. I don't think that will work here, as the projects under SimplyEdit are too diverse. For the PHPCSStandards composer-installer a project specific CONTRIBUTING.md was created, but there is already talk of expanding this into a separate DEVELOPING.md (heading into wall-of-text territory).

I am wondering if we might want "just" add the .vscode specific file for now, so we can take our time to have a broader discussion about how to solve the education/documentation issue. It might be worth not documenting Electron development (and debugging) in this repo but as a separate entity. Especially if we plan to create other/more Electron apps using SimplyCode.

In that case, my proposition would be:

• Merge this MR
• Either close or reword & merge Add details for install, usage and development. #3
• Create a separate ticket (or discussion, or whatever) where a more long-term discussion can be held regarding how to deal with these (and other) docs.

Thoughts?

[Hoxolotl]

As discussed at the office: we'll speed up by merging this until supporting IDE's becomes an issue.

[Potherca]

Discussed in person, suggested resolution stand: Merge now, docs later.