emulate

repository·main·Indexed 23 days ago

https://github.com/vercel-labs/emulate

emulate provides local, stateful, production-fidelity API emulation for services such as Vercel, GitHub, AWS, Stripe, and Resend. Designed for CI environments and no-network sandboxes, it acts as a drop-in replacement for real APIs rather than simple mocks. It supports standalone processes via npx emulate or embedded integration within Next.js and Nuxt applications using @emulators/adapter-next and @emulators/adapter-nuxt.

Tokens
150.5K
Snippets
286
Records
712
Agent score
77%

What's inside emulate

  1. GitHub API Emulator Capabilities

    main
    The GitHub API emulator provides a fully stateful environment. All operations (Create, Update, Delete) persist in memory and affect related entities, allowing for realistic testing of complex workflows. The emulator supports a wide range of endpoints including Users, Repositories, Issues, Pull Requests, Webhooks, Actions, and Search.
  2. Use the Linear GraphQL API emulator

    main

    The @emulators/linear package provides a stateful GraphQL API emulator for local development and CI. It targets a focused subset of the Linear GraphQL API.

    API Surface

    • Endpoint: POST /graphql
    • Supported Queries: viewer, organization, users, teams, workflow states, issues, comments, labels, projects, cycles, webhooks, and agent sessions.
    • Supported Mutations: issues, comments, labels, webhooks, and basic agent sessions and activities.

    Authentication

    • Supports Personal API keys and OAuth bearer tokens.
    • Supports OAuth flows: authorize, token, refresh, revoke, PKCE, client credentials, and app actor tokens.

    Webhooks

    • Delivers Linear-shaped webhooks including the following headers:
      • Linear-Delivery
      • Linear-Event
      • Linear-Signature

    Inspector

    • A local inspector is available at the root path (/).

    OAuth Actor Configuration

    The actor configuration determines the authorization flow:

    • actor: user: Uses authorization code flows.
    • actor: app: Uses the app install flow and can request client credentials tokens.

    Note: This is not a complete Linear clone. Any unsupported GraphQL fields will return GraphQL errors.

  3. How Slack event dispatching works

    main

    When the Slack emulator performs state-mutating writes, it dispatches event_callback payloads to configured webhook URLs. These payloads follow Slack's standard Events API format. Supported event types include:

    • Messages: message events for chat.postMessage, chat.update (subtype message_changed), chat.delete (subtype message_deleted), and incoming webhooks (subtype bot_message).
    • Reactions & Pins: reaction_added/reaction_removed for reactions.add/reactions.remove, and pin_added/pin_removed for pins.add/pins.remove.
    • Lifecycle: channel_archive/channel_unarchive (public), group_archive/group_unarchive (private), and channel_rename/group_rename.
    • Channel Metadata: message with channel_topic/channel_purpose (public) or group_topic/group_purpose (private) subtypes.
    • Membership: member_joined_channel and member_left_channel for invite, join, leave, and kick actions.
    • Direct Messages/MPIM: im_created, im_open, im_close, im_marked, and group open/close/marked events.
    • User & Presence: user_change for profile writes and presence_change for presence writes.
    • Files: file_created, file_shared, file_deleted, and message with subtype file_share for shared file uploads.
  4. Authenticate with the AWS Emulator

    main

    The emulator uses Bearer token authentication. Pass tokens via the Authorization: Bearer <token> header. Permissions are scoped using patterns like s3:*, sqs:*, iam:*, and sts:*.

    Example Request

    curl http://localhost:4006/ \
      -H "Authorization: Bearer test_token_admin"
  5. How OAuth emulation works

    main

    The OAuth emulation flow follows these steps:

    1. Authorization Request: Clicking a provider button redirects the user to /api/auth/[provider]. This route constructs the OAuth authorize URL and redirects the browser to the local emulator.
    2. User Selection: The emulator presents a user-picker page. You select a seeded user from the list.
    3. Callback with Code: The emulator redirects the browser back to the application's callback route (/api/auth/callback/[provider]) including an authorization code.
    4. Token Exchange: The application's callback route exchanges the authorization code for an access token, retrieves user information, and establishes a session via an HTTP-only cookie.
    5. Authentication: The application dashboard displays the authenticated user's profile and the retrieved access token.
  6. How persistence works in Nuxt emulators

    main

    The persistence lifecycle follows these rules:

    1. Cold start: The adapter attempts to load() state from the persistence adapter. If found, it restores the Store and token map. If not found, it seeds from the provided config and saves the initial state.
    2. Mutating requests: After POST, PUT, PATCH, or DELETE requests, the state is saved via the adapter. Saves are serialized through an internal queue to prevent race conditions.
    3. No configuration: If no persistence adapter is provided, the system falls back to pure in-memory storage, meaning seed data re-initializes on every cold start.