async-framework async-framework .cursorrules file for JavaScript (stars: 8)

// Repository-specific rules for Cursor AI

// General guidelines
Always prefer TypeScript unless explicitly required like any of the examples apps thats also using .js
Preserve existing comments in all files
Follow the project structure as defined in the repository

// Deno configuration
This is a Deno project
Refer to deno.jsonc for Deno-specific configurations
Update .vscode/settings.json when adding new packages or directories that should be managed by Deno

// Project structure
Maintain the following package structure:
  - packages/
    - examples/
    - async-framework/
    - dev/
    - custom-element-signals/
Add new packages under the 'packages/' directory
Add new example toy apps in 'examples/' directory
Add anything for the local dev-server in 'dev/' directory such as the server.ts which is the deno server hosting the example apps

// VS Code settings
When adding new packages, update the "deno.enablePaths" in .vscode/settings.json
Example:
  "deno.enablePaths": [
    "./packages/examples",
    "./packages/async-framework",
    "./packages/dev",
    // Add new package paths here
  ]

// File-specific guidelines
For HTML files:
  - Use proper HTML5 structure
  - Include necessary script tags for custom elements and signals
For JavaScript files:
  - Use ES6+ syntax
  - Prefer const over let when variables are not reassigned
For TypeScript files:
  - Use TypeScript features judiciously
  - Provide clear type annotations for function parameters and return types

// Custom elements and signals
When working with custom elements:
  - Use kebab-case for custom element names
  - Extend HTMLElement for custom elements
  - Use connectedCallback for initialization logic

// Best practices
Follow single responsibility principle for functions and classes
Use meaningful variable and function names
Keep functions small and focused
Use async/await for asynchronous operations
Implement error handling where appropriate

// Testing
Write unit tests for new functionality
Ensure all tests pass before committing changes

// Documentation
Add comments for complex logic or non-obvious code
Update README files when adding new features or changing existing ones
Make sure every method in 'async-framework/' folder has a "Why:" comment above to explain why it's there

// Version control
Make small, focused commits with clear commit messages
Create feature branches for new developments

// Performance
Optimize for performance, especially in signal handling and custom element operations
Avoid unnecessary re-renders or computations

// README formatting
When creating or updating README files, do not use backticks (`) around code examples unless it's already there

// Deno Import guidelines
Always use import aliases defined in deno.jsonc
Never use direct HTTP imports
For Hono, always use the npm version via the import alias
Examples of correct imports:
  import { Hono } from "hono";
  import { assertEquals } from "@std/assert";
  import { signal } from "custom-element-signals";
Examples of incorrect imports:
  import { Hono } from "https://deno.land/x/hono@v3.x/mod.ts";
  import { assertEquals } from "https://deno.land/std/assert/mod.ts";

// Deno Version
Use Deno 2.0 or higher for this project
Key Deno 2.0 features to leverage:
  - Native npm module support
  - Enhanced TypeScript support
  - Built-in test runner
  - Improved Node.js compatibility
  - Enhanced security with permissions system
For detailed documentation and features, refer to:
  - Runtime Manual: https://docs.deno.com/runtime/manual
  - API Reference: https://docs.deno.com/runtime/api
  - Examples: https://docs.deno.com/runtime/examples

// Remember to update this file as the project evolves and new standards are established