Project: Refactor to separate out actual logic from VSCode extension (presentation layer)

[DeflateAwning]

I want to refactor this project to separate out the "business logic" from the VS Code extension library.

Would you accept the following refactor in a PR?

Motivation

1. Enable usage in a CI GitHub Action pipeline (implement #192)
2. Make it easier to fix #174 (firmware root in subfolder in workspace)
3. Better code architecture, testability, etc.

Implementation Details

• The main focus will be on separating out the VS Code Extension vs. Makefile generation. Initially, parts like debugging, OpenOCD, etc. will be lumped in with the VS Code Extension.
• Plan: Create a new module/package for the business logic that is independent of the VS Code API, in this repo.
• File contents and paths: The new module will primarily use strings of file contents and lists-of-paths, so that both a CI pipeline (using shelljs) and the vscode extension (using the vscode module) can easily use them. It will be filesystem-agnostic.
• Errors: The new module will use the TypeScript error system (i.e., throw Error()) instead of vscode.window.xxx.
• Measure of success: A new shelljs-based script, with CLI args "pathToFirmwareFolder", which generates the Makefile completely devoid of vscode, can be constructed trivially.

[jortbmd]

Thanks for opening up an issue for this. I do agree that this is useful. The initial version of the extension actually had this separation, however the code duplication between the cli tool and the extension became significant. So this is something I am wary of. For now to make CI/CD work I was working on making the Makefile machine agnostic, this way it can be committed in git and be used as a normal makefile in a CI/CD pipeline.

If the logic would be separated I would prefer to a have a model similar to platfom.io where the main tool would be the cli, and the extension would be a thin wrapper which sends io to the cli for both set-up and building, this way the scope of the project can be extended to other IDE's as well. For this however I do not feel that javascript/typescript would necessarily be the best choice in language as the entire runtime should be included and started when spinning up a command, which might impact performance.

For these reasons I will be hesitant to accept small rewrites into cli script unless I can see it contributing it to a larger picture. I am telling you this not to discourage you, but to prevent you doing in a lot of work which might not result in an accepted pull request. However as stated I am not averse to the idea and would very much like to hear your thoughts on it on how you want to proceed and what you propose for an initial structure and technologies to be used.

[DeflateAwning]

Great feedback! I have some time to contribute to this at the moment (and so does my team), and we'd would love to help!

Would you like to advise what the best path is? I like the idea with the Platform.io architecture. I also like the idea of the normal version-controlled Makefile, probably. My pet peve is having to update the Makefiles with file lists (prevalent in both CMake and Make).

From my initial planning of the proposed changes, I think this should be possible with nearly 0% code reuse.

I'm not a huge fan of Typescript either (at least not yet). We have a decent amount of Python experience; any chance that's what you were thinking of?

[jortbmd]

The makefile should be the STM32 for VSCode generated one. It should be up to date with the current application after pressing build. If this is committed it should be good and in line with the application. The only thing you need to watch out for at that point is merging the Makefile correctly.

I for one am not particularly fond of Python and therefore I am hesitant to include it as a language. I would prefer something that can be statically compiled and with static type checking, that is relatively performant like: C/C++, Go or Rust, across platforms. This way external dependencies can be limited and we can ship a single binary that does not depend on a run-time. I do have to admit though that my experience with both Rust and Go are limited, so it would also be a bit of a learning experience for me.

Just to clarify my point about code re-use, although I am guessing we mean the same thing. I do not care about re-use of the code either way, however I care about the responsibility/functionality of the code e.g. there should not be two pieces of code which have the same responsibility/functionality for both the cli application and the extension.

Im thinking of how we can move forward with this. It might be nice if you could create an architecture diagram or something which shows what your idea of the system would be, so we can use this as input to move forward. I can imagine however that this might be a bit too much of an investment. Just to re-iterate thank you for your ideas and thinking along it really is appreciated!