From b500d3a99b7f8272c15148c776bab9e3ed4a6f7d Mon Sep 17 00:00:00 2001 From: buttercat1791 Date: Sat, 24 May 2025 00:06:07 -0500 Subject: [PATCH 1/4] Write Cursor style guide for Svelte files --- .cursor/rules/svelte-style.mdc | 90 ++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 .cursor/rules/svelte-style.mdc diff --git a/.cursor/rules/svelte-style.mdc b/.cursor/rules/svelte-style.mdc new file mode 100644 index 0000000..c23295e --- /dev/null +++ b/.cursor/rules/svelte-style.mdc @@ -0,0 +1,90 @@ +--- +description: +globs: *.svelte +alwaysApply: false +--- +# Svelte Style + +Observe the the following style guidelines when programming Svelte components or SvelteKit pages: + +- Always use idiomatic Svelte 5 syntax and features. Svelte 5 idioms include: + - Runes, such as `$state`, `$derived`, `$effect`, and `$props`. + - Callback props. + - Snippets. +- Avoid using deprecated Svelte 4 syntax and features. Depecrated features include: + - Props declared via `export let`. + - Event handlers attached via the `on:` directive. + - Event dispatchers. + - Component slots. +- Remember that Svelte 5 state is deeply reactive. + - Mutating a state object automatically triggers reactivity in most cases. + - Avoid trying to trigger reactivity by reassigning state variables unless other options have failed. +- Write components in TypeScript, and prefer strong typing for variables, props, and function signatures. +- Limit component logic to rendering concerns. Extract business logic into separate TypeScript modules, and import functions and classes into Svelte components as needed. + +## Component Code Organization Example + +When writing or editing a Svelte component, organize the code according to the following template: + +``` + + + +{#snippet contentParagraph(content: string, publicationType: string, isSectionStart: boolean)} +
+ {@html content} +
+{/snippet} + + +
+ {#await leafEvent} + {@render contentParagraph(leafEvent.content.toString(), publicationType ?? 'article', false)} + {/await} +
+ + + +``` \ No newline at end of file From f4d9874983d884076143ef6e9e0cdb4c477f8a7c Mon Sep 17 00:00:00 2001 From: buttercat1791 Date: Sat, 24 May 2025 19:35:31 -0500 Subject: [PATCH 2/4] Add TS style rules --- .cursor/rules/typescript-style.mdc | 54 ++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 .cursor/rules/typescript-style.mdc diff --git a/.cursor/rules/typescript-style.mdc b/.cursor/rules/typescript-style.mdc new file mode 100644 index 0000000..21f31f0 --- /dev/null +++ b/.cursor/rules/typescript-style.mdc @@ -0,0 +1,54 @@ +--- +description: +globs: *.ts,*.svelte +alwaysApply: false +--- +# TypeScript Style + +Observe the following style guidelines when writing TypeScript code. + +## Naming Conventions + +- Use `snake_case` for TypeScript files (`*.ts`). +- Use `PascalCase` for classes, interfaces, types, enums, and enum members. +- Use `camelCase` for functions and variables, and class members. +- Avoid abbreviations in class, enum, function, and variable names. +- Denote private class members with the `#` prefix, as added in the ECMAScript 2022 (ES2022) specification. + +## Type Annotations + +- Always use type annotations when declaring class properties. +- Use type annotations when declaring variables that are not immediately instantiated, or whose type is not apparent from the declaration expression. +- Type annotations may be omitted when declaring a variable whose value is assigned at declaration time, and whose value can be clearly discerned from this assignment. +- Always use type annotations when a variable may be `null` or `undefined`. +- Optional interface members or function parameters may be denoted with `?`. +- Always annotate the types of function parameters. +- Always annotate the return types of functions, unless the return type is `void`, in which case the type annotation may be omitted. + +## Formatting + +- Use an indent of two spaces. +- Place a semicolon at the end of each complete statement. +- Use single-quotes by default for string literals, and backticks where single-quotes do not apply. +- Limit line length to 100 characters. +- Split expressions across lines when they are too long to fit on a single line. +- Use the priority-ordered list of directives below to determine where to put line breaks when splitting expressions. Apply the minimum number of rules necessary to fit the expression within the 100-character line length limit. + - If the expression contains curly brackets (`{}`), split after the first curly bracket, and place the trailing curly bracket on its own line. + - If the expression contains square brackets (`[]`), split after the first square bracket, and place the trailing square bracket on a new line. + - If the expression contains parentheses (`()`), split after the first parenthesis, and place the trailing parenthesis on its own line. + - If the expression contains comma-separated lists, put each value in the list on its own line. + - If the expression contains assignment `=`, put a line break immediately before the assignment operator. +- Split long ternary expressions across multiple lines, with the `?` and `:` operators at the head of each new line. +- Always wrap the bodies of control flow blocks (`if`/`else`, `for`, `do`/`while`, `switch`) in curly brackets (`{}`), even when the compiler does not require it. +- In functions or control flow blocks, place the initial `{` on the same line as the function signature or control flow expression. +- The `return` statement may be omitted from the end of a function when the function returns `void`. + +## Comments + +- Use JSDoc comments to describe all functions or variables that are exported by a module or are part of a class's public interface. +- Use comments sparingly within function bodies. +- Code should typically be self-documenting, with descriptive names and clear organization. +- When a long comment is needed to describe a difficult-to-understand bit of code, begin the comment with the name of the developer leaving the comment and the date, e.g.: `// Michael J - 24 May 2025 -`. +- Use multi-line comments to keep the line length of comments from surpassing the 100-character line length limit for code. + + From e1b3ec95e115ffe0832b7def5bc2aac4728ddf21 Mon Sep 17 00:00:00 2001 From: buttercat1791 Date: Sat, 24 May 2025 19:35:41 -0500 Subject: [PATCH 3/4] Update Svelte component rules --- .cursor/rules/svelte-style.mdc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.cursor/rules/svelte-style.mdc b/.cursor/rules/svelte-style.mdc index c23295e..66a97d0 100644 --- a/.cursor/rules/svelte-style.mdc +++ b/.cursor/rules/svelte-style.mdc @@ -21,6 +21,8 @@ Observe the the following style guidelines when programming Svelte components or - Avoid trying to trigger reactivity by reassigning state variables unless other options have failed. - Write components in TypeScript, and prefer strong typing for variables, props, and function signatures. - Limit component logic to rendering concerns. Extract business logic into separate TypeScript modules, and import functions and classes into Svelte components as needed. +- Use PascalCase when naming Svelte components. +- Keep component files under 500 lines, when possible. ## Component Code Organization Example From 072d41dd4942896f63db886b00e66174d3d9562d Mon Sep 17 00:00:00 2001 From: buttercat1791 Date: Sat, 24 May 2025 19:35:55 -0500 Subject: [PATCH 4/4] Remove redundant general rule --- .cursor/rules/alexandria.mdc | 1 - 1 file changed, 1 deletion(-) diff --git a/.cursor/rules/alexandria.mdc b/.cursor/rules/alexandria.mdc index 4fe24b0..7a0724f 100644 --- a/.cursor/rules/alexandria.mdc +++ b/.cursor/rules/alexandria.mdc @@ -36,7 +36,6 @@ Observe the following style guidelines when writing code: ### General Guidance -- Use PascalCase names for Svelte 5 components and their files. - Use snake_case names for plain TypeScript files. - Use comments sparingly; code should be self-documenting.