Review workspace settings

[gcsecsey]

Describe the bug Looking at .vscode/settings.json, there are numerous workspace settings that change the basic look & feel of the editor. As these settings have no effect on the code pushed to the repo, IMO these should be set on the user level instead of the workspace level.

To Reproduce

Looking at some settings in .vscode/settings.json:

• These settings only affect the UI of VSCode:

  {
  "editor.fontSize": 15,
  "editor.tabSize": 2,
  "editor.suggestSelection": "first",
  "editor.minimap.enabled": false,
  }

• These settings are nice to have on the workspace level, but I think should be up to user preference. We should instead rely on pre-commit hooks and code validation on a CI/CD pipeline (eg. via GH actions) to enforce linting/formatting rules:

  {
  "editor.formatOnSave": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    // [Error - 9:45:52 PM] Error: Error while loading rule '@nrwl/nx/enforce-module-boundaries': ENOENT: no such file or directory, open '/Users/roblevin/workspace/opensource/agnosticui/nx.json'
    //   "typescript",
    "typescriptreact"
  ],  
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  }

• These settings reference plugins which aren't necessarily installed on any contributor's machines. We could add plugins that are required to work with the repo as workspace recommended extensions, so that VSCode offers to install these automatically:

  {
  "webhint.enableTelemetry": "disabled",
  "vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue"
  }

• These settings can be overridden when formatting is run from the command line (eslint or prettier):

  {
  "html.format.wrapAttributes": "force-aligned",
  "[html]": {
    "editor.defaultFormatter": "vscode.html-language-features"
  },
  "vetur.format.defaultFormatter.html": "js-beautify-html",
  "[vue]": {
    "editor.defaultFormatter": "octref.vetur"
  }
  }

Expected behavior

We should strive to enforce linting/formatting rules on the server side, and/or in pre-commit hooks. This would make contributing to the project easier with other IDEs and independent of IDE settings.

[roblevintennis]

I agree with all you've said. I think I was just moving fast while going solo but it doesn't fit for collaboration!

For now what's the recommendation exactly? Delete the vscode config and add to gitignore?

[gcsecsey]

I'm not sure whether we should delete the whole config. For the editor settings, we can go ahead and remove the setting, but for others, it would be better to substitute them with the appropriate git hook or GH action.

I can go over each setting and raise a PR with the easy ones removed, and some others replaced, lmk if that's OK. 🙂

[roblevintennis]

Thanks 🙏🏽 @gcsecsey that makes sense!