obsidian-livesync/.prettierrc

{
    "trailingComma": "es5",
    "tabWidth": 4,
    "printWidth": 120,
    "semi": true,
    "endOfLine": "crlf"
}
chore(format): adds prettier and commands to run it ... including ci/cd check-only commands. The code is quite complex and missing a lot of dev-ops types checks and standards. One of the key problems with codebases like this is on-boarding new developers to the codebase (like myself). When there is a consistent and enforced coding-style (irrespective of what the coding style is) it makes it _significantly_ easier for collaborators and maintainers to get on with the job in hand. It also, from a day-2-day developer perspective, significantly reduces cognitive overhead re reading code. Finally this is a "trial balloon" PR, if this patch is accepted I will likely do more work on testing and docs for the project. - The new prettier config is a non-standard setup, but a close-match to how the code _currently_ looks. - 120 col-width print width (instead of the better and more information-dense 88), this is so the diff after applying prettier to the code is less disruptive, whilst still showing the benefits of using a prettier. - We use `tabWidth` setting of 4 as the code uses that more common setting instead of the more compact 2 spaces - note that 2 often leads to more readable and compact code. - We enforce trailing commas, as that seems to be the norm in this code-base. We choose the `es5` standard here. - We enforce tailing semi-colons (`semi`) as the majority of code used that flavour of `js`/`ts`. - For now we only run on code and not json files. This is designed such that `npm run pretty` re-formats the code for development, and when integrated with ci/cd, `prettyCheck` will return non-zero exit codes when formatting doesn't match the coding standards. 2024-11-11 08:45:24 +02:00			`{`
I have adapted the new-line-char to the codebase. But I am not sure if this is the right thing to do. 2024-11-12 03:04:46 +02:00			`"trailingComma": "es5",`
			`"tabWidth": 4,`
			`"printWidth": 120,`
			`"semi": true,`
			`"endOfLine": "crlf"`
chore(format): adds prettier and commands to run it ... including ci/cd check-only commands. The code is quite complex and missing a lot of dev-ops types checks and standards. One of the key problems with codebases like this is on-boarding new developers to the codebase (like myself). When there is a consistent and enforced coding-style (irrespective of what the coding style is) it makes it _significantly_ easier for collaborators and maintainers to get on with the job in hand. It also, from a day-2-day developer perspective, significantly reduces cognitive overhead re reading code. Finally this is a "trial balloon" PR, if this patch is accepted I will likely do more work on testing and docs for the project. - The new prettier config is a non-standard setup, but a close-match to how the code _currently_ looks. - 120 col-width print width (instead of the better and more information-dense 88), this is so the diff after applying prettier to the code is less disruptive, whilst still showing the benefits of using a prettier. - We use `tabWidth` setting of 4 as the code uses that more common setting instead of the more compact 2 spaces - note that 2 often leads to more readable and compact code. - We enforce trailing commas, as that seems to be the norm in this code-base. We choose the `es5` standard here. - We enforce tailing semi-colons (`semi`) as the majority of code used that flavour of `js`/`ts`. - For now we only run on code and not json files. This is designed such that `npm run pretty` re-formats the code for development, and when integrated with ci/cd, `prettyCheck` will return non-zero exit codes when formatting doesn't match the coding standards. 2024-11-11 08:45:24 +02:00			`}`