-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy path.cursorrules
More file actions
150 lines (116 loc) · 5.06 KB
/
.cursorrules
File metadata and controls
150 lines (116 loc) · 5.06 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
// Solid.js with Tailwind CSS .cursorrules
// Prefer functional components
const preferFunctionalComponents = true;
// Solid.js and Tailwind CSS best practices
const solidjsTailwindBestPractices = [
"Use createSignal() for reactive state",
"Implement Tailwind CSS classes for styling",
"Utilize TypeScript's strict mode",
"Utilize @apply directive in CSS files for reusable styles",
"Implement responsive design using Tailwind's responsive classes",
"Use Tailwind's CSS in /src/styles.css for global styles",
"Implement dark mode using Tailwind's dark variant",
];
// Additional instructions
const additionalInstructions = `
1. Use .tsx extension for files with JSX
2. Implement strict TypeScript checks
3. Implement proper Tailwind CSS purging for production builds
4. Utilize TanStack Router for routing when applicable
5. Use type-safe context with createContext
6. Implement proper typing for event handlers
7. Follow TypeScript best practices and naming conventions
8. Use type assertions sparingly and only when necessary
9. Use Tailwind's @layer directive for custom styles
10. Implement utility-first CSS approach
11. Follow both Solid.js and Tailwind naming conventions
12. Use JIT (Just-In-Time) mode for faster development
`;
We use Sentry for watching for errors in our deployed application, as well as for instrumentation of our application.
## Error collection
Error collection is automatic and configured in `src/router.tsx`.
## Instrumentation
We want our server functions intstrumented. So if you see a function name like `createServerFn`, you can instrument it with Sentry. You'll need to import `Sentry`:
```tsx
import * as Sentry from '@sentry/browser'
```
And then wrap the implementation of the server function with `Sentry.startSpan`, liks so:
```tsx
Sentry.startSpan({ name: 'Requesting all the pokemon' }, async () => {
// Some lengthy operation here
await fetch('https://api.pokemon.com/data/')
})
```
This document serves as some special instructions when working with Convex.
# Schemas
When designing the schema please see this page on built in System fields and data types available: https://docs.convex.dev/database/types
Here are some specifics that are often mishandled:
## v (https://docs.convex.dev/api/modules/values#v)
The validator builder.
This builder allows you to build validators for Convex values.
Validators can be used in schema definitions and as input validators for Convex functions.
Type declaration
Name Type
id <TableName>(tableName: TableName) => VId<GenericId<TableName>, "required">
null () => VNull<null, "required">
number () => VFloat64<number, "required">
float64 () => VFloat64<number, "required">
bigint () => VInt64<bigint, "required">
int64 () => VInt64<bigint, "required">
boolean () => VBoolean<boolean, "required">
string () => VString<string, "required">
bytes () => VBytes<ArrayBuffer, "required">
literal <T>(literal: T) => VLiteral<T, "required">
array <T>(element: T) => VArray<T["type"][], T, "required">
object <T>(fields: T) => VObject<Expand<{ [Property in string | number | symbol]?: Exclude<Infer<T[Property]>, undefined> } & { [Property in string | number | symbol]: Infer<T[Property]> }>, T, "required", { [Property in string | number | symbol]: Property | `${Property & string}.${T[Property]["fieldPaths"]}` }[keyof T] & string>
record <Key, Value>(keys: Key, values: Value) => VRecord<Record<Infer<Key>, Value["type"]>, Key, Value, "required", string>
union <T>(...members: T) => VUnion<T[number]["type"], T, "required", T[number]["fieldPaths"]>
any () => VAny<any, "required", string>
optional <T>(value: T) => VOptional<T>
## System fields (https://docs.convex.dev/database/types#system-fields)
Every document in Convex has two automatically-generated system fields:
_id: The document ID of the document.
_creationTime: The time this document was created, in milliseconds since the Unix epoch.
You do not need to add indices as these are added automatically.
## Example Schema
This is an example of a well crafted schema.
```ts
import { defineSchema, defineTable } from "convex/server";
import { v } from "convex/values";
export default defineSchema(
{
users: defineTable({
name: v.string(),
}),
sessions: defineTable({
userId: v.id("users"),
sessionId: v.string(),
}).index("sessionId", ["sessionId"]),
threads: defineTable({
uuid: v.string(),
summary: v.optional(v.string()),
summarizer: v.optional(v.id("_scheduled_functions")),
}).index("uuid", ["uuid"]),
messages: defineTable({
message: v.string(),
threadId: v.id("threads"),
author: v.union(
v.object({
role: v.literal("system"),
}),
v.object({
role: v.literal("assistant"),
context: v.array(v.id("messages")),
model: v.optional(v.string()),
}),
v.object({
role: v.literal("user"),
userId: v.id("users"),
}),
),
})
.index("threadId", ["threadId"]),
},
);
```
Sourced from: https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/convex-cursorrules-prompt-file/.cursorrules