Adopt Prettier for code style

[VitGottwald]

Having a unified code style within a repository has many advantages:

• The code becomes easier to read because it follows the same, predictable visual pattern
• Easier onboarding. Anyone new to the project can rely on the formatting patterns and does not have to learn different styles in different files.
• Pull requests do not show changes caused by reformatting code that did not actually change. This can happen accidentally or by using a different editor.
• Easier code authoring. Developers can focus on the logical structure of their code without having to worry about formatting. The formatting tool takes care of that.

[VitGottwald]

Currently our code base does not follow a unified code formatting style. For javascript and typescript codebases Prettier is the de-facto standard used by the majority of projects.

Lets’ adopt prettier for ZOWE Explorer.

[phaumer]

I converted the FTP extension to eslint with prettier here. If people like this approach then we can apply the same here, but a lot of fixing will be required, which could be a good thing.

https://github.com/zowe/zowe-explorer-ftp-extension/tree/add-eslint-prettier-support

[VitGottwald]

Thank you @phaumer for taking the initiative. I completely agree. Let's discuss it in your PR for the FTP plugin and once merged and tested, we can then come up with a suggestion for this repo.

[phaumer]

We we had a really good discussion in zowe/zowe-explorer-ftp-extension#3 and zowe/zowe-explorer-ftp-extension#4

and have a proposal for a starting point for this repo as well: https://github.com/zowe/zowe-explorer-ftp-extension

Next steps:

• go through specific rules we want to enable
• plan a transition strategy for updating our code base as getting the ideal set of rules will be a slow process of updating the code case by case. We can discuss using warning and switching rules gradually over time.

[VitGottwald]

Thank you @phaumer for leading this effort! I think we can break this down a bit more.

The very first step can be reformatting the codebase with prettier without enabling any new linting rules. This will require only minimal manual effort.

Then we can continue a separate discussion as you suggested in next steps. Perhaps in a separate issue dedicated to linting rules.