chore: Add cursor rules. (#864)

Adds an initial set of cursor rules. These rules can be changes if
issues are encountered. The goal is to make cursor more adept at working
in this repository.

Author: kinyoklion

.cursor/rules/dependencies.mdc

@@ -0,0 +1,30 @@
+---
+description: Rules about dependencies.
+globs: *
+alwaysApply: true
+---
+# Dependency Management Guidelines
+
+## General Principles
+- Dependencies should be avoided unless absolutely necessary
+- Consider the following factors when evaluating dependencies:
+  - Size: Impact on final bundle size (especially important for browser SDK)
+  - Maintenance: Risk of becoming unmaintained or deprecated
+  - Security: Potential security vulnerabilities
+  - Compatibility: Support across all target platforms
+  - Conflicts: Potential conflicts with application dependencies
+
+## Package-Specific Guidelines
+- Most important to avoid dependencies in:
+  - common package
+  - sdk-client package
+  - sdk-server package
+- Individual SDK packages may have specific platform dependencies
+- Edge SDKs must use their provider's edge store and may require specific dependencies
+
+## Dependency Selection Criteria
+- Only use dependencies for functionality with:
+  - Highly-specified behavior
+  - Wide usage
+  - Active maintenance
+  - Large community support

.cursor/rules/development.mdc

@@ -0,0 +1,30 @@
+---
+description: Rules for building and understanding the repository.
+globs: *
+alwaysApply: true
+---
+# General Development Guidelines
+
+## Project Structure
+- This is a monorepo containing multiple JavaScript SDK packages
+- Packages are organized into categories:
+  - Shared packages (common code)
+  - SDK packages (platform-specific implementations)
+  - Store packages (persistent storage)
+  - Telemetry packages (monitoring)
+  - Tooling packages (development tools)
+
+## Build Requirements
+- Node environment version 16 required, this is a minimum.
+- yarn required
+- Some projects may have specific environment prerequisites
+
+## Build Process
+- Use `yarn` to install dependencies from project root
+- Use `yarn build` to build all projects
+- For single project builds:
+  ```
+  yarn workspaces foreach -pR --topological-dev --from '@launchdarkly/js-client-sdk' run build
+  ```
+- Replace package name as needed
+- Running `yarn build` in individual packages won't rebuild dependencies

.cursor/rules/linting.mdc

@@ -0,0 +1,63 @@
+---
+description: Rules for finding and addressing linting issues.
+globs: *.ts
+alwaysApply: true
+---
+# Linting Guidelines
+
+## Running Lint Checks
+
+Lint checks can be run for any package using the following command:
+
+```bash
+yarn workspace <package name> lint
+```
+
+For example, to lint the common SDK package:
+
+```bash
+yarn workspace @launchdarkly/js-sdk-common lint
+```
+
+## Fixing Lint Issues
+
+Many lint issues can be automatically fixed using the `--fix` flag:
+
+```bash
+yarn workspace <package name> lint --fix
+```
+
+For example:
+
+```bash
+yarn workspace @launchdarkly/js-sdk-common lint --fix
+```
+
+## Manual Fixes
+
+If automatic fixes don't resolve all issues, you should fix them manually. Pay special attention to:
+
+- TypeScript type errors
+- ESLint rule violations
+- Code style inconsistencies
+
+## Mock Type Handling
+
+When working with mocks in tests, it's acceptable to use ESLint ignore or TypeScript ignore comments if typing issues arise. This is only appropriate for test mocks, not for implementation code.
+
+Example:
+
+```typescript
+// @ts-ignore - Mock implementation doesn't need full typing
+const mockClient = {
+  // mock implementation
+};
+```
+
+## Package Names
+
+Package names can be found in the respective `package.json` files. Always use the exact package name as specified there when running lint commands.
+
+## When to Run Lint
+
+- Run lint checks on any package you've modified

.cursor/rules/testing.mdc

@@ -0,0 +1,52 @@
+---
+description: Rules for running and developing tests.
+globs: *
+alwaysApply: true
+---
+# Testing Guidelines
+
+## Test Structure
+- Unit tests should be implemented in a `__tests__` folder in the root of the package
+- The directory structure inside of `__tests__` should mirror that of the source directory
+- Tests should only be run for single projects
+
+## Test Naming and Organization
+- Test cases should be written using `it` and should read as a sentence including the `it`
+- Example: `it('does not load flags prior to start', async () => {/* test code */})`
+- Describe blocks should ONLY be used for common setup for a series of tests
+- Example: `describe('given a mock filesystem and memory feature store', { /* tests */})`
+- If there is no shared configuration, do not use a describe block
+- Combined test names should be understandable: `given a mock filesystem and memory feature store > it does not load flags prior to start`
+
+- Example of proper describe usage:
+  ```javascript
+  describe('given a mock filesystem and memory feature store', () => {
+    // Shared setup code here
+    
+    it('does not load flags prior to start', async () => {
+      // Test code
+    });
+    
+    it('loads flags after start', async () => {
+      // Test code
+    });
+  });
+  ```
+- Example of when not to use describe:
+  ```javascript
+  // No shared configuration, so no describe block needed
+  it('returns true when flag is enabled', () => {
+    // Test code
+  });
+  
+  it('returns false when flag is disabled', () => {
+    // Test code
+  });
+  ```
+
+## Running Tests
+- Tests should be run using `yarn workspace <package name> test`
+- The package name can be found in the package.json file
+- Unit tests should be run for any packages that have been modified
+
+

.cursor/rules/typescript.mdc

@@ -0,0 +1,20 @@
+---
+description:  Rules for typescript development.
+globs: *.ts
+alwaysApply: true
+---
+# TypeScript Guidelines
+
+## TypeScript vs JavaScript
+- While we develop in TypeScript, aim for compiled JavaScript to not be substantially different than if written as JavaScript
+- Consider JavaScript consumers when making TypeScript decisions
+
+## TypeScript Best Practices
+- Avoid using TypeScript enumerations. Instead use unions of strings
+  - Bad: `enum ValueType { Bool = 'bool', Int = 'int' }`
+  - Good: `type ValueType = 'bool' | 'int'`
+- Prefer interfaces over classes when reasonable, especially if publicly exposed
+  - Bad: Using classes for simple data structures
+  - Good: Using interfaces with factory functions
+- Remember that `private` and `readonly` only affect TypeScript - JavaScript can still access and mutate
+- For private members that need to be minified, prefix with underscore