Add VScode settings to the repository checked in source code.

[KevinMind]

Describe the problem and steps to reproduce it:

This project relies on several libraries that require specific IDE settings in order to have a productive workflow. Specifically for VS Code any developer will depend on a few critical settings and a few useful extensions to make development both possible and delightful.

1. Flow types are not natively supported in VS code and conflict with the built in typescript type system. In order to bypass this setting, we should disable javascript validation and use flow validation.
2. Our project relies on eslint,stylelint, css-modules and git. We can recommend the best supported extensions for these libraries to provide intellisense and editor inline linting for code.

What happened?

VS Code interprets flow types as typescript types.

https://github.com/mozilla/addons-frontend/assets/19595165/25acdba2-02fa-4cd5-a53a-ded566dc71ec

This is because VS Code has built in support for typescript intellisense even for javascript code, by default. Even if the flowtype.flow-for-vscode is installed the javascript language server will interpret the types as typescript types.

Flow typing

Extensions for css

Enable autocomolete for css modules

Enable inline error reports for stylelint

Anything else we should know?

• You could argue that adding vscode specific settings will alienate developers who use other IDEs. (Intelij, Sublime, vim, neovim)

This is true, but there is no reason why an .editorconfig or a vendor specific file could not be maintained by users of other IDEs. .editorconfig is not usable by VScode natively so I would not argue against using it, but it does not totally solve the problem for vs code users.

Additionally, it is undeniable that VScode now accounts for the lion share of IDE usage. According to TOP IDE Index VS Code alone accounts for more than the other editors mentioned above combined. This is not to discount other IDEs, anyone can use whatever they want. But there is strong support for having vs code specific settings as it will address a large chunk of developers.

• You could argue that vscode users should maintain their own local settings and extensions.

To this I would respond that after you have worked on a few projects you end up with many extensions installed, and it is always a pain to remember which ones are related to which project?

https://github.com/mozilla/addons-frontend/assets/19595165/e3f2760f-efbc-4c0d-ba73-b047bce31d0e

Keeping the settings tied to a project frees you from needing to keep track individually which settings and extensions are needed if you change machines or otherwise lose track.

Furthermore there are typically more than one extension for a given use case, and having a set "recommended" list ensures that developers working on this project are more likely to use the same extensions and thus have consistent experiences, preventing "it works on my machine" type of issues, especially with linting.

┆Issue is synchronized with this Jira Task

[KevinMind]

Old Jira Ticket: https://mozilla-hub.atlassian.net/browse/ADDFRNT-299