prettier format

Author: notunderctrl

CONTRIBUTING.md

@@ -49,6 +49,7 @@ git checkout -b your-feature-or-bugfix
 3. Ensure that your changes don't break any existing functionality.
    You can test the functionality of your code depending on where
    you've made changes:
+
    1. If you've made changes to the CommandKit package, you can use
       the "apps/test-bot" project to test your own bot. Just make sure
       to create a new `.env` file with the template from the

apps/website/docs/guide.old/01-getting-started/05-using-commandkit-cli.mdx

@@ -103,11 +103,13 @@ npx commandkit create event ready
 ## Best Practices
 
 1. **Development Workflow**:
+
    - Use `commandkit dev` during development for instant feedback
    - Enable debug mode when troubleshooting issues
    - Keep your `.env` file updated with all required variables
 
 2. **Production Deployment**:
+
    - Always run `commandkit build` before deploying
    - Test the production build locally before deployment
    - Use environment variables for sensitive data

apps/website/docs/guide.old/04-caching/01-caching-in-commandkit.mdx

@@ -80,11 +80,13 @@ CommandKit's caching system works by:
 
 1. **Generating a Cache Key**: Each cached function call generates a
    unique key based on:
+
    - The function's identity
    - The arguments passed to the function
    - A build ID for stability
 
 2. **Storing Results**: When a function is called:
+
    - If the result isn't cached, the function executes and stores its
      result
    - If the result is cached, it's returned immediately without
@@ -116,16 +118,19 @@ async function fetchUserData(userId: string) {
 ## Best Practices
 
 1. **Choose What to Cache**:
+
    - Cache expensive operations (API calls, database queries)
    - Cache data that doesn't change frequently
    - Don't cache sensitive or frequently changing data
 
 2. **Set Appropriate TTL**:
+
    - Use shorter TTL for frequently changing data
    - Use longer TTL for static data
    - Consider your data's update frequency
 
 3. **Use Tags for Revalidation**:
+
    - Add meaningful tags to your cache entries
    - Group related cache entries with the same tag
    - Use tags for targeted cache invalidation

apps/website/docs/guide.old/04-caching/02-cacheTag-function.mdx

@@ -83,11 +83,13 @@ await revalidateTag('user:123');
 ## Best Practices
 
 1. **Use Consistent Naming**:
+
    - Follow a consistent pattern (e.g., `type:id`)
    - Make tags descriptive and meaningful
    - Use hierarchical tags when appropriate
 
 2. **Group Related Data**:
+
    - Tag related cache entries with the same tag
    - Use multiple tags for cross-category entries
    - Consider data relationships when tagging

apps/website/docs/guide.old/04-caching/03-cacheLife-function.mdx

@@ -103,11 +103,13 @@ async function fetchData(type: 'frequent' | 'rare') {
 ## Best Practices
 
 1. **Choose Appropriate Duration**:
+
    - Use shorter TTL for frequently changing data
    - Use longer TTL for static content
    - Consider your data update patterns
 
 2. **Balance Freshness and Performance**:
+
    - Don't cache too long if data changes often
    - Don't cache too short if data is static
    - Consider your application's needs

apps/website/docs/guide.old/04-caching/05-revalidateTag-function.mdx

@@ -73,11 +73,13 @@ setInterval(
 ## Best Practices
 
 1. **Strategic Invalidation**:
+
    - Invalidate only what needs to be refreshed
    - Use specific tags for targeted invalidation
    - Consider the impact on performance
 
 2. **Timing**:
+
    - Invalidate after data changes
    - Consider using scheduled revalidation
    - Balance freshness and performance

apps/website/docs/guide.old/04-caching/06-cleanup-function.mdx

@@ -72,11 +72,13 @@ async function performConservativeCleanup() {
 ## Best Practices
 
 1. **Choose Appropriate Time Period**:
+
    - Consider your application's memory constraints
    - Balance between memory usage and cache effectiveness
    - Monitor cache hit rates
 
 2. **Schedule Regular Cleanup**:
+
    - Set up automated cleanup tasks
    - Choose appropriate intervals
    - Handle cleanup errors gracefully

apps/website/docs/guide/14-useful-utilities/01-ratelimit.mdx

@@ -1,11 +1,15 @@
 ---
 title: Rate Limiter
-description: Control request frequency with configurable limits and intervals
+description:
+  Control request frequency with configurable limits and intervals
 ---
 
 # Rate Limiter
 
-Think of a rate limiter like a traffic light for your application. It controls how often something can happen - like how many times a user can click a button or make an API request. This prevents your system from being overwhelmed.
+Think of a rate limiter like a traffic light for your application. It
+controls how often something can happen - like how many times a user
+can click a button or make an API request. This prevents your system
+from being overwhelmed.
 
 ## Basic Usage
 
@@ -27,7 +31,8 @@ if (allowed) {
 
 ## Custom Configuration
 
-Sometimes you need different limits for different situations. You can create a custom rate limiter with specific settings:
+Sometimes you need different limits for different situations. You can
+create a custom rate limiter with specific settings:
 
 ```typescript
 import { createRateLimiter } from 'commandkit/ratelimit';
@@ -45,21 +50,28 @@ const allowed = await apiLimiter.limit('api:endpoint');
 
 ### Checking Remaining Requests
 
-You can check how many requests a user has left and when the limit resets:
+You can check how many requests a user has left and when the limit
+resets:
 
 ```typescript
-import { getRemainingRequests, getResetTime } from 'commandkit/ratelimit';
+import {
+  getRemainingRequests,
+  getResetTime,
+} from 'commandkit/ratelimit';
 
 const remaining = await getRemainingRequests('user:123');
 const resetTime = await getResetTime('user:123');
 
 console.log(`${remaining} requests remaining`);
-console.log(`Limit resets in ${Math.round(resetTime / 1000)} seconds`);
+console.log(
+  `Limit resets in ${Math.round(resetTime / 1000)} seconds`,
+);
 ```
 
 ### Manual Reset
 
-In some cases, you might want to reset a user's rate limit (like after they upgrade their account):
+In some cases, you might want to reset a user's rate limit (like after
+they upgrade their account):
 
 ```typescript
 import { resetRateLimit } from 'commandkit/ratelimit';
@@ -70,7 +82,9 @@ await resetRateLimit('user:123');
 
 ### Using External Storage
 
-By default, rate limiters store data in memory. If you're running multiple servers, you'll want to use external storage like Redis so all servers can share the same rate limit information:
+By default, rate limiters store data in memory. If you're running
+multiple servers, you'll want to use external storage like Redis so
+all servers can share the same rate limit information:
 
 ```typescript
 import { RateLimiter, RateLimitStorage } from 'commandkit/ratelimit';
@@ -81,7 +95,11 @@ import { Redis } from 'ioredis';
 const redis = new Redis();
 
 // Use Redis-based rate limit storage
-const limiter = new RateLimiter(10, 60000, new RedisRateLimitStorage(redis));
+const limiter = new RateLimiter(
+  10,
+  60000,
+  new RedisRateLimitStorage(redis),
+);
 ```
 
 You can also use the convenience function:
@@ -106,14 +124,21 @@ const limiter = createRateLimiter({
 ## Common Use Cases
 
 - **API Rate Limiting**: Prevent users from making too many API calls
-- **User Action Throttling**: Limit how often users can click buttons or submit forms
+- **User Action Throttling**: Limit how often users can click buttons
+  or submit forms
 - **Resource Access Control**: Control access to expensive operations
-- **Spam Prevention**: Stop automated bots from overwhelming your system
+- **Spam Prevention**: Stop automated bots from overwhelming your
+  system
 
 ## Tips for Beginners
 
-1. **Start Simple**: Use the default `ratelimit()` function for basic needs
-2. **Choose Good Keys**: Use descriptive keys like `user:123` or `api:endpoint` to make debugging easier
-3. **Set Reasonable Limits**: Don't make limits too strict or too loose - find the right balance
-4. **Handle Rejection**: Always check if the rate limit allows the action before proceeding
-5. **Consider Your Users**: Think about legitimate use cases when setting limits
+1. **Start Simple**: Use the default `ratelimit()` function for basic
+   needs
+2. **Choose Good Keys**: Use descriptive keys like `user:123` or
+   `api:endpoint` to make debugging easier
+3. **Set Reasonable Limits**: Don't make limits too strict or too
+   loose - find the right balance
+4. **Handle Rejection**: Always check if the rate limit allows the
+   action before proceeding
+5. **Consider Your Users**: Think about legitimate use cases when
+   setting limits

apps/website/docs/guide/14-useful-utilities/02-mutex.mdx

@@ -1,15 +1,20 @@
 ---
 title: Mutex
-description: Ensure exclusive access to shared resources with async mutex locks
+description:
+  Ensure exclusive access to shared resources with async mutex locks
 ---
 
 # Mutex
 
-A mutex is like a "do not disturb" sign for your data. It ensures that only one operation can access a shared resource at a time. Imagine multiple people trying to edit the same document - a mutex makes sure only one person can edit it at once.
+A mutex is like a "do not disturb" sign for your data. It ensures that
+only one operation can access a shared resource at a time. Imagine
+multiple people trying to edit the same document - a mutex makes sure
+only one person can edit it at once.
 
 ## Basic Usage
 
-The easiest way to use a mutex is with the `withMutex` function, which automatically handles locking and unlocking:
+The easiest way to use a mutex is with the `withMutex` function, which
+automatically handles locking and unlocking:
 
 ```typescript
 import { withMutex } from 'commandkit/mutex';
@@ -41,7 +46,8 @@ const result = await mutex.withLock('resource', async () => {
 
 ### Manual Lock Management
 
-Sometimes you need more control over when locks are acquired and released:
+Sometimes you need more control over when locks are acquired and
+released:
 
 ```typescript
 import { acquireLock, releaseLock, isLocked } from 'commandkit/mutex';
@@ -65,7 +71,8 @@ console.log(`Resource is ${locked ? 'locked' : 'available'}`);
 
 ### Cancelling Operations
 
-You can cancel a mutex operation if it takes too long or if you need to stop it for any reason:
+You can cancel a mutex operation if it takes too long or if you need
+to stop it for any reason:
 
 ```typescript
 import { withMutex } from 'commandkit/mutex';
@@ -91,7 +98,9 @@ try {
 
 ### Using External Storage
 
-By default, mutexes store lock information in memory. If you're running multiple servers, you'll want to use external storage like Redis:
+By default, mutexes store lock information in memory. If you're
+running multiple servers, you'll want to use external storage like
+Redis:
 
 ```typescript
 import { Mutex, MutexStorage } from 'commandkit/mutex';
@@ -127,17 +136,26 @@ const mutex = createMutex({
 
 ## Common Use Cases
 
-- **Database Transactions**: Ensure only one operation can modify data at a time
-- **File System Access**: Prevent multiple operations from writing to the same file
-- **Configuration Updates**: Make sure configuration changes don't conflict
-- **Cache Invalidation**: Control when cache is cleared to prevent race conditions
+- **Database Transactions**: Ensure only one operation can modify data
+  at a time
+- **File System Access**: Prevent multiple operations from writing to
+  the same file
+- **Configuration Updates**: Make sure configuration changes don't
+  conflict
+- **Cache Invalidation**: Control when cache is cleared to prevent
+  race conditions
 - **Resource Pool Management**: Manage access to limited resources
 
 ## Tips for Beginners
 
-1. **Use `withMutex` When Possible**: It automatically handles cleanup, so you don't forget to release locks
-2. **Set Reasonable Timeouts**: Don't make timeouts too short (might fail unnecessarily) or too long (might hang forever)
-3. **Use Descriptive Names**: Give your resources meaningful names like `user:123:profile` or `database:users`
+1. **Use `withMutex` When Possible**: It automatically handles
+   cleanup, so you don't forget to release locks
+2. **Set Reasonable Timeouts**: Don't make timeouts too short (might
+   fail unnecessarily) or too long (might hang forever)
+3. **Use Descriptive Names**: Give your resources meaningful names
+   like `user:123:profile` or `database:users`
 4. **Handle Errors**: Always handle cases where lock acquisition fails
-5. **Think About Deadlocks**: Be careful not to create situations where two operations wait for each other
-6. **Consider Your Setup**: Use external storage if you have multiple servers
+5. **Think About Deadlocks**: Be careful not to create situations
+   where two operations wait for each other
+6. **Consider Your Setup**: Use external storage if you have multiple
+   servers