Browse

Automation .cursorrules strategies

Filters

Tech

Clear

Chrome extension APIs

Tanstack Query

expo-secure-store

Expo SDK

expo-notifications

Server Components

Lucide

NativeWind

react-native.

Github

Stripe

Server Actions

Replicate

Anthropic

Deepgram

docker-compose

LSM tree

MVCC (Multi-Version Concurrency Control)

containerization technologies

Dockerfile

cProfile

database algorithms

asyncio

B+ tree

WAL (Write-Ahead Logging)

multiprocessing

B-tree

functional programming

GitHub Actions.

boto3

python

flask-cors

FUE5

flask

conda

SVG

gunicorn

svgwrite

CSS.

Clerk Auth

mySQL

tailwindcss.

Flask-RESTful

Flask-Caching

Flask-SQLAlchemy

Flasgger.

Flask-JWT-Extended

Flask-RESTX

Flask-Migrate

SplashScreen

react-native-i18n

React's Suspense

Views

Blueprints

expo-error-reporter

React Native

expo-updates

expo-constants

react-native-gesture-handler

react-native-safe-area-context

React Context

Redux Toolkit

react-native-encrypted-storage

expo-permissions

AppLoading

expo-localization

Extensions.

react-native-reanimated

react-query

expo-linking

useReducer

Symfony

postgres

Sqlite3

SQLAlchemy 2.0

Magic UI

Go's testing package

net/http

ServeMux

log

HTTP

React three fiber

Three.js

Cypress.

Cloudflare Workers

Cloudflare D1

EAS

Jotai

Deno

@tanstack/react-query

react-copy-to-clipboard

@rainbow-me/rainbowkit

react-hot-toast

nextjs

eslint-config-prettier

eslint

daisyui

abitype

vercel

@types/nprogress

Playwright TypeScript Guide .cursorrules prompt file

Playwright Testing - Best Practices

Always use TypeScript instead of vanilla JavaScript whenever possible.
For locators, always bias towards using Playwright's getByTestId() locator method to target elements, unless absolutely unable to do so.
1. If using getByTestId() is not possible, then using a getByRole() locator is the next best option.
2. If using getByRole() is not possible, then using a getByPlaceholder() or getByLabel() or getByAltText() locator is the next best option.
3. If using getByPlaceholder() or getByLabel() or getByAltText() is not possible, then using a getByText() locator is the next best option.
  1. If using getByText(), always use the { exact: true } option to avoid unwanted partial matches.
4. If using getByText() is not possible, then use whatever locator Playwright allows you to use to target the element.
  1. If using an Xpath or CSS selector is necessary, please try to take the shortest path to target the element and leverage any available attributes to target the element.
Save any locator to a variable before using it in a test. Examples:
DO:
```typescript
const exampleSignInButton = page.getByTestId("ExampleButton_signIn");
await exampleSignInButton.click();
```
DON'T:
```typescript
await page.getByTestId("ExampleButton_signIn").click();
```
If logic is being reused in multiple tests, recommend creating a reusable helper/utility function to share this logic across tests. a. If a helper function is created to follow the DRY principle, don't require more arguments in the function than are needed to share the logic. b. Never assert anything in a helper function. Helper functions are reserved for performing a series of user actions, not testing the outcome of those actions.
Whenever possible, use Playwright's built-in features, methods, and utilities instead of "reinventing the wheel" with raw JavaScript or TypeScript solutions to solved problems. Examples:
DO:
```typescript
await expect(async () => {
await radioButton.click(); // locator defined outside this block
await expect(radioButton).toBeChecked();
}).toPass();
```
DON'T:
```typescript
export async function radioButtonGroupClick(
page: Page,
urlToWaitFor: string, // The URL where the radio button is
radioButton: Locator,
errorTextTrigger: Locator // A button you can click that will throw error text if the radio button wasn't clicked
) {
await page.waitForURL(urlToWaitFor);
let iterationCounter = 0;
let errorTextIsVisible = await page.getByTestId("ErrorText").isVisible();
let buttonWasClicked = await radioButton.isChecked();
while (errorTextIsVisible || !buttonWasClicked) {
if (iterationCounter === 5) {
break;
} else {
iterationCounter++;
}
await radioButton.click();
buttonWasClicked = await radioButton.isChecked();
if (buttonWasClicked) {
await errorTextTrigger.click();
errorTextIsVisible = await page.getByTestId("ErrorText").isVisible();
}
}
}
```
The entry point to Playwright's documentation is here if you need to look available features: https://playwright.dev/docs/intro.
When doing so follows the other rules in this file, try to write tests similar to other existing tests in the Playwright suite. The Playwright suite consists of everything within the tests/ directory.

stack:

Playwright

TypeScript

JavaScript

Playwright TypeScript Guide .cursorrules prompt file

Steven Boutcher

0

NEW

Deno Integration Techniques .cursorrules prompt file

@findhow Automation

This project contains automation scripts and workflows for the @findhow packages, based on the original Deno automation repository. The goal is to provide consistent and efficient automation for the @findhow ecosystem.

Purpose

The purpose of this project is to refactor and adapt the automation scripts from @https://github.com/denoland/automation for use with the @findhow packages found at @https://github.com/zhorton34/findhow.

Project Guidelines

Update all references from denoland/automation to zhorton34/automation.
Modify scripts to work with @findhow packages instead of @std packages.
Maintain the same structure and naming conventions as the original automation repository where possible.
Update configuration files to reflect the new @findhow ecosystem.
Adapt existing documentation to reflect the @findhow context.
Ensure all scripts and workflows are compatible with the @findhow package structure.
Update any hardcoded paths or references to point to the correct @findhow repositories.

Cursor AI Assistance

When working on this project, Cursor AI should:

Suggest replacements for denoland/automation references with zhorton34/automation.
Help identify and update package references from @std to @findhow.
Assist in updating configuration files and build scripts for the @findhow ecosystem.
Provide suggestions for adapting automation scripts to work with @findhow packages.
Offer insights on best practices for Deno package automation.
Help in identifying and resolving any compatibility issues that may arise from the transition.
Assist in updating examples and usage instructions in README files.

Version Control

When making changes:

Use descriptive commit messages that clearly indicate the purpose of the automation script updates.
Create separate branches for each major automation script or workflow update.
Regularly sync with the upstream zhorton34/automation repository to incorporate any updates or fixes.
Assist in creating pull request templates for automation updates.

Testing and Quality Assurance

Ensure all automation scripts are tested with @findhow packages.
Update test files to use the new @findhow namespace where applicable.
Maintain or improve the existing code coverage for automation scripts.
Ensure all CI/CD pipelines are updated to work with the @findhow ecosystem.
Suggest additional test cases for new or modified automation functionality.

Documentation

When updating documentation:

Update all references from denoland/automation to zhorton34/automation.
Update examples to use @findhow packages instead of @std packages.
Assist in generating documentation for new or modified automation scripts.
Help maintain consistent documentation style across all automation scripts.

Script Structure

When creating or modifying automation scripts:

Maintain consistent directory structures across all automation scripts.
Suggest appropriate file naming conventions for new scripts.
Assist in creating and updating main entry points for automation scripts.
Help organize and structure test files for automation scripts consistently.

Integration with @findhow

Ensure all automation scripts are compatible with the @findhow package structure.
Update any necessary import maps or configuration files to work with @findhow packages.
Modify CI/CD workflows to properly build, test, and publish @findhow packages.
Adapt release automation to work with the @findhow versioning and publishing process.

Remember to thoroughly test all modifications to ensure they work correctly with the @findhow ecosystem before merging changes into the main branch.

stack:

Deno